- NANOG - lists.nanog.org

re: Fwd: MPLS acceptable latency?
by eric-list＠truenet.com 15 Nov '12

15 Nov '12

<bold>My humble opinion</bold> SLAs are more for accountants and lawyers. Get the right tech support on the phone and you can solve most issues without all the hassle. SLAs really are minimal if you can contact the right people and work through the problem. +1 to Level3 and Cogent as I have had some of the best trouble shooting for even minimal problems... ---------------------------------------- From: "david peahi" <davidpeahi(a)gmail.com> Sent: Thursday, November 15, 2012 3:31 PM To: nanog(a)nanog.org Subject: Fwd: MPLS acceptable latency? ---------- Forwarded message ---------- From: david peahi <davidpeahi(a)gmail.com> Date: Thu, Nov 15, 2012 at 12:15 PM Subject: Re: MPLS acceptable latency? To: Mikeal Clark <mikeal.clark(a)gmail.com> Assuming no configuration errors, this underscores the need to negotiate SLAs, and serious SLA penalties, with the telcos, and to always request a telco network map, with the telco path that data will be transitting end-to-end.. My rule of thumb in network design is that data over copper or fiber takes 10 ms per 1000 miles, which is governed by the speed of light. Network devices along the path add serialization/de-serialization delay, but with modern network devices this delay is negligible. So according to this rule of thumb 85 ms is almost enough time for data to traverse the USA 3 times. I have found that telcos have been setting round trip SLAs so high that they are meaningless (e.g. 50 ms for a GigE MEF ELAN service, 20 ms for "Gold" MEF EVPL service), and border on being fraudulent. In one case I also noted 100 ms round trip times between sites less than 1 mile away, and discovered that every packet was being sent back to east Texas from Southern California, almost a 5000 mile detour.

1 0

Fwd: MPLS acceptable latency?
by david peahi 15 Nov '12

15 Nov '12

---------- Forwarded message ---------- From: david peahi <davidpeahi(a)gmail.com> Date: Thu, Nov 15, 2012 at 12:15 PM Subject: Re: MPLS acceptable latency? To: Mikeal Clark <mikeal.clark(a)gmail.com> Assuming no configuration errors, this underscores the need to negotiate SLAs, and serious SLA penalties, with the telcos, and to always request a telco network map, with the telco path that data will be transitting end-to-end.. My rule of thumb in network design is that data over copper or fiber takes 10 ms per 1000 miles, which is governed by the speed of light. Network devices along the path add serialization/de-serialization delay, but with modern network devices this delay is negligible. So according to this rule of thumb 85 ms is almost enough time for data to traverse the USA 3 times. I have found that telcos have been setting round trip SLAs so high that they are meaningless (e.g. 50 ms for a GigE MEF ELAN service, 20 ms for "Gold" MEF EVPL service), and border on being fraudulent. In one case I also noted 100 ms round trip times between sites less than 1 mile away, and discovered that every packet was being sent back to east Texas from Southern California, almost a 5000 mile detour. On Thu, Nov 15, 2012 at 10:54 AM, Mikeal Clark <mikeal.clark(a)gmail.com>wrote: > Hello! > > I have some AT&T MPLS sites under a managed contract with latency > averaging 75-85 ms without any load. These sites are only 45 minutes > away. What is considered normal/acceptable? > > Thanks, > >

1 0

Re: MPLS acceptable latency?
by Scott Weeks 15 Nov '12

15 Nov '12

--- jared(a)puck.nether.net wrote: On Nov 15, 2012, at 2:15 PM, Scott Weeks wrote: > --- mikeal.clark(a)gmail.com wrote: > I have some AT&T MPLS sites under a managed contract with latency > averaging 75-85 ms without any load. These sites are only 45 minutes > away. What is considered normal/acceptable? > -------------------------------------------- > Coast-to-coast latency is around 60-65msec, so that's high. What link speed? Perhaps he's using ISDN or a T1? Serialization delay is not to be ignored. ------------------------------------------------- I believe serialization delay is so small as to not be very noticeable. A coast-to-coast T1 (that is not full) should have no more latency than a coast-to-coast DS-3 or any other circuit. After all, the T1 is muxed up and then down crossing the same BACs in the middle. The only serialization delay that is different is at the end points. scott (BAC = Big Ass Circuit :)

1 0

Re: MPLS acceptable latency?
by Wes Tribble 15 Nov '12

15 Nov '12

I concur. We have sites all over the US and it is about 80-100 ms from coast to coast with both of our MPLS providers. 45 minutes away your latency should be <5ms on a decent network. ------------------------------------------------- --- mikeal.clark(a)gmail.com wrote: From: Mikeal Clark <mikeal.clark(a)gmail.com> I have some AT&T MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? -------------------------------------------- Coast-to-coast latency is around 60-65msec, so that's high. scott

1 0

Re: Brasil/Mexico/Argentina connectivity
by alejandroacostaalamo＠gmail.com 15 Nov '12

15 Nov '12

Hi Jima, I can help you contacting BT if you need so. Alejandro, ------Mensaje original------ De: Jima Para: nanog(a)nanog.org Asunto: Re: Brasil/Mexico/Argentina connectivity Enviado: 15 nov, 2012 11:35 On Wednesday, November 14th, 2012, Olivier CALVANO wrote: > I am search one or more carrier for connect 3 sites in Brasil, Mexico > and Argentina to one of our pop > in USA or Spain. I don't deal with it directly, but my employer has used MPLS offerings from (in alphabetical order) BT, Level 3/Global Crossing, and Verizon in a number of countries. I suspect any of the three have access in all of the countries listed. I imagine there are others, but those are the ones that sprung to mind. Jima Este mensaje ha sido enviado gracias al servicio BlackBerry de Movilnet

1 0

Brasil/Mexico/Argentina connectivity
by Olivier CALVANO 15 Nov '12

15 Nov '12

Hi I am search one or more carrier for connect 3 sites in Brasil, Mexico and Argentina to one of our pop in USA or Spain. if you have a name and contact ;=) best regards Olivier

2 1

Eaton 9130 UPS feedback
by Seth Mattinen 15 Nov '12

15 Nov '12

Does anyone use Eaton 9130 series UPS for anything? I'm curious how they've worked out for you. I bought a 700VA model to give it a whirl versus the traditional APC since the Eaton is an online type with static bypass and also does some high efficiency thing where it normally stays on bypass, but the first thing it did on the bench was have the inverter/rectifier or bypass section catch on fire and destroy itself. ~Seth

17 20

APRICOT 2013 in Singapore
by Philip Smith 15 Nov '12

15 Nov '12

Hi everyone, Just to let you know that the call for papers for APRICOT 2013 (in Singapore next February) opened a few days ago. Rather than posting the whole cfp here, you can see it via the programme page on the APRICOT website - www.apricot2013.net/program. NANOG and APRICOT are the network operations conferences for adjacent regions - and indeed both regions have considerable overlap and interests in common. Please give some thought to presenting something topical at APRICOT - the Programme Committee would love to hear from you. You can submit your proposal via http://papers.apricot.net. Thanks! philip (on behalf of the APRICOT PC) --

1 0

Ethernet NID plus POE+ (802.3at)... or POE+ injector with OAM...
by Robert E. Seastrom 14 Nov '12

14 Nov '12

Hi everyone, I'm looking for a gigabit ethernet media converter to go from SFP plugable optics to 802.3at POE+. The application involves wireless access points some distance from a central switch for a venue. Difficulty: in my old age, I've become allergic to installing completely unmanaged bump-in-the-wire devices that can't be monitored in some way. They make for a big nuisance when it comes time to debug the installation. The metro ethernet folks have brought us 802.1ag, 802.3ah, and Y.1731. Even the simplest of these - .1ag L2 ping (LBM/LBR) - is sufficient for my purposes of making sure that we're bidirectionally passing traffic. I'm aware of pluggable optics that do OAM (OEsolution Smart SFP) as well as some piggyback devices from other sources. I'd like to find a single box though that will do my media conversion, POE+ injection, and response to OAM packets all in one convenient tiny enclosure. Bonus points for well-thought-out details such as DIN rail mounting capability and cable retention tricks. Anyone got any pointers? -f

2 1

DHCPv6 and MAC addresses
by Ray Soucy 14 Nov '12

14 Nov '12

Saw yet another attempt at a solution pop up to try and deal with the lack of a MAC address in DHCPv6 messages. I've been giving this some thought about how this should be best accomplished without requiring that host implementations of DHCPv6 be modified. Taking advantage of the relay-agent seems to be the most elegant solution: 1) Any DHCPv6 server on a local segment will already have access to the MAC address; but having a DHCPv6 server on each segment is not ideal. 2) Requests that are relayed flow through a relay-agent, which is on a device that also has access to the MAC address of the client system. Option A: RFC 6422 provides for Realy-Supplied DHCP Options, currently with one option code registered with IANA (OPTION_ERP_LOCAL_DOMAIN_NAME). You can see the list here: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml I think the quickest solution would be: 1) Adding an RSOO for the client MAC address 2) Get vendors on board to draft and adopt a standard for it on routers, 3) Modify DHCPv6 servers to have support for MAC identification based on the MAC of the local request OR the MAC of the relayed request when the option is present. Option B: The current RELAY-FORW message already includes the link-local address of the client. Perhaps there should be a modification to the privacy extensions RFC to forbid the use of privacy addressing on the link-local scope; at this point we could modify DHCPv6 servers to be able to determine the MAC address for relayed requests based on their link-local address. Unfortunately, the cat is out of the bag on this one, so it would take time to get host implementations modified. I might be overlooking something critical... thoughts? -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net

2 2