I guess you answered your own question: "And I'm not sure what faster switching/routing has to do with MPLS:)" As far as CEF and such goes, I couldn't disagree with that (as I was not comparing MPLS to other optimized forwarding techniques), however, MPLS is not a vendor-proprietary forwarding mechanism, which means that I can deploy it worldwide, or state-wide, whatever the case may be, in my network and have the benefit of using only ONE protocol with MPLS-enabled/aware routers/switches. A definate plus over the other proprietary fast switching techniques you mentioned. Your last statement indicates "added services" have nothing to do with the the fast switching processing of MPLS, when in fact these services depend upon the faster delivery of the non-proprietary fast switching of MPLS. As quoted from the rfc: "This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services." Marc -----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 11:20 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks I still have to disagree that MPLS results in faster switching/routing in modern service provider networks. Modern vendor caching mechanisms are just as fast if not faster than MPLS processing. With the small overhead of MPLS labels and LDP I highly doubt that you're getting any performance increase over Cisco's CEF or Juniper's FPC architecture. I also doubt that speed is a benefit that service providers consider when deciding whether or not they want to implement MPLS. Added services that run on top of MPLS like VPNs, traffic engineering, and fast rerouting capabilities (all mentioned in the original post) are more likely the benefits considered. Perhaps when label switching was first being marketed (Ipsilon and Cisco in 1996) there were some speed benefits but now I think it's the services that use MPLS that are the major benefit. -Michael Cohen -----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:59 AM To: 'mcohen@thrupoint.net'; 'nanog@merit.edu' Subject: RE: MPLS in metro access networks soooo...Label switching assigns labels to packet headers which results in less time and processing looking up routes, and instead relies upon a label index for forwarding decisions? Hence my statement "faster switching/routing and less processing":) Marc -----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:56 AM To: Quibell, Marc Subject: RE: MPLS in metro access networks I hope so:) -----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:46 AM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks Are we talking about Multiprotocol Label Switching? Marc -----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:45 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks And I'm not sure what faster switching/routing has to do with MPLS:) I believe one of the ideas behind MPLS benefiting metro access networks is using MPLS to deliver layer 2 VPNs across an MPLS enabled core thus simulating leased lines for access clients...but I'm sure somebody will correct me if I'm wrong. There seems to be some hype for Martini draft VPNs and large enterprise customers in metro areas. Cheers, -Michael Cohen -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Quibell, Marc Sent: Thursday, November 15, 2001 10:20 AM To: 'srihari varada'; nanog@merit.edu Subject: RE: MPLS in metro access networks I would think faster switching/routing and less processing would be wanted in any mid-to-large sized network...I'm not sure what load balancing and fault restoration has to do with MPLS.... Marc -----Original Message----- From: srihari varada [mailto:varada@txc.com] Sent: Thursday, November 15, 2001 10:12 AM To: nanog@merit.edu Subject: MPLS in metro access networks Hello: I have heard some stressing the role of MPLS in metro access networks. It is difficult for me to visualize the need for it in them while it is not so difficult to understand the utility (load balancing and fault restoration etc.) of it in the metro backbone networks. To characterize metro access networks in the context, the following is provided: -- aggregates traffic from residential (arriving via broadband access links such as xDSL, Cable) and business consumers (arriving via broadband access links such as xDSL and high speed links such as Ethernet or SONET) -- funnels aggregated traffic to metro backbone networks for destination hosts in the local metro region or remote regions across the internet regional and backbone networks. Majority of such access networks are SONET/ATM based (I didn't come across any case of Gig Ethernet. However, I do not preculde it). Thus, there are two questions: -- Are there known RBOCs/ILECs and CLECs entrenching MPLS in the said network scope? (I do not see many major ILECs in the un-official MPLS service providers list being circulated but it may mean little) -- If so, what motivates them to do so? Any analysis of the driving forces is appreciated. Regards, Srihari Varada
Maybe I'm getting confused. The original post asked the question "what motivates them" (RBOCs, ILECs, and CLECs) to implement MPLS. You answered that fast switching/routing was a reason. I disagree with this because designing and implementing MPLS just for speed benefits is a bit too cumbersome and complex compared to using local caching mechanisms that are just as fast, if not faster. Saying that using MPLS as an alternative to using local caching mechanisms because of standardization doesn't make sense to me either because the local caching mechanisms are in place regardless. In fact, you can't run MPLS on most vendor hardware without running their proprietary caching (Cisco mandates using CEF before implementing MPLS and Juniper uses it's FPC hardware architecture regardless of MPLS). So to add to my point, there is no speed benefit in running MPLS if you are already using modern caching techniques, which most service providers interested in MPLS are already doing. To respond to your second point regarding using added services I agree completely that these services require MPLS labels to work. However, this still has nothing to do with speed benefits. You say "these services depend upon the faster delivery" of MPLS but the RFC doesn't mention speed at all. It just says "This approach uses MPLS running in the backbone to provide premium services". Any MPLS added service uses label stacking which allows for the RFC stated "premium services". Cheers, -Michael Cohen -----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 12:04 PM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks I guess you answered your own question: "And I'm not sure what faster switching/routing has to do with MPLS:)" As far as CEF and such goes, I couldn't disagree with that (as I was not comparing MPLS to other optimized forwarding techniques), however, MPLS is not a vendor-proprietary forwarding mechanism, which means that I can deploy it worldwide, or state-wide, whatever the case may be, in my network and have the benefit of using only ONE protocol with MPLS-enabled/aware routers/switches. A definate plus over the other proprietary fast switching techniques you mentioned. Your last statement indicates "added services" have nothing to do with the the fast switching processing of MPLS, when in fact these services depend upon the faster delivery of the non-proprietary fast switching of MPLS. As quoted from the rfc: "This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services." Marc -----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 11:20 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks I still have to disagree that MPLS results in faster switching/routing in modern service provider networks. Modern vendor caching mechanisms are just as fast if not faster than MPLS processing. With the small overhead of MPLS labels and LDP I highly doubt that you're getting any performance increase over Cisco's CEF or Juniper's FPC architecture. I also doubt that speed is a benefit that service providers consider when deciding whether or not they want to implement MPLS. Added services that run on top of MPLS like VPNs, traffic engineering, and fast rerouting capabilities (all mentioned in the original post) are more likely the benefits considered. Perhaps when label switching was first being marketed (Ipsilon and Cisco in 1996) there were some speed benefits but now I think it's the services that use MPLS that are the major benefit. -Michael Cohen -----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:59 AM To: 'mcohen@thrupoint.net'; 'nanog@merit.edu' Subject: RE: MPLS in metro access networks soooo...Label switching assigns labels to packet headers which results in less time and processing looking up routes, and instead relies upon a label index for forwarding decisions? Hence my statement "faster switching/routing and less processing":) Marc -----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:56 AM To: Quibell, Marc Subject: RE: MPLS in metro access networks I hope so:) -----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:46 AM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks Are we talking about Multiprotocol Label Switching? Marc -----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:45 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks And I'm not sure what faster switching/routing has to do with MPLS:) I believe one of the ideas behind MPLS benefiting metro access networks is using MPLS to deliver layer 2 VPNs across an MPLS enabled core thus simulating leased lines for access clients...but I'm sure somebody will correct me if I'm wrong. There seems to be some hype for Martini draft VPNs and large enterprise customers in metro areas. Cheers, -Michael Cohen -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Quibell, Marc Sent: Thursday, November 15, 2001 10:20 AM To: 'srihari varada'; nanog@merit.edu Subject: RE: MPLS in metro access networks I would think faster switching/routing and less processing would be wanted in any mid-to-large sized network...I'm not sure what load balancing and fault restoration has to do with MPLS.... Marc -----Original Message----- From: srihari varada [mailto:varada@txc.com] Sent: Thursday, November 15, 2001 10:12 AM To: nanog@merit.edu Subject: MPLS in metro access networks Hello: I have heard some stressing the role of MPLS in metro access networks. It is difficult for me to visualize the need for it in them while it is not so difficult to understand the utility (load balancing and fault restoration etc.) of it in the metro backbone networks. To characterize metro access networks in the context, the following is provided: -- aggregates traffic from residential (arriving via broadband access links such as xDSL, Cable) and business consumers (arriving via broadband access links such as xDSL and high speed links such as Ethernet or SONET) -- funnels aggregated traffic to metro backbone networks for destination hosts in the local metro region or remote regions across the internet regional and backbone networks. Majority of such access networks are SONET/ATM based (I didn't come across any case of Gig Ethernet. However, I do not preculde it). Thus, there are two questions: -- Are there known RBOCs/ILECs and CLECs entrenching MPLS in the said network scope? (I do not see many major ILECs in the un-official MPLS service providers list being circulated but it may mean little) -- If so, what motivates them to do so? Any analysis of the driving forces is appreciated. Regards, Srihari Varada
Srihari: I'm going to attempt to answer your original question:
-- If so, what motivates them to do so? Any analysis of the driving forces is appreciated.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Michael Cohen Sent: Friday, November 16, 2001 3:45 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks
Maybe I'm getting confused. The original post asked the question "what motivates them" (RBOCs, ILECs, and CLECs) to implement MPLS. You answered that fast switching/routing was a reason. I disagree with this because designing and implementing MPLS just for speed benefits is a bit too cumbersome and complex compared to using local caching mechanisms that are just as fast, if not faster. Saying that using MPLS as an alternative to using local caching mechanisms because of standardization doesn't make sense to me either because the local caching mechanisms are in place regardless. In fact, you can't run MPLS on most vendor hardware without running
proprietary caching (Cisco mandates using CEF before implementing MPLS and Juniper uses it's FPC hardware architecture regardless of MPLS). So to add to my point, there is no speed benefit in running MPLS if you are already using modern caching techniques, which most service providers interested in MPLS are already doing.
To respond to your second point regarding using added services I agree completely that these services require MPLS labels to work. However,
still has nothing to do with speed benefits. You say "these services depend upon the faster delivery" of MPLS but the RFC doesn't mention speed at all. It just says "This approach uses MPLS running in the backbone to
premium services". Any MPLS added service uses label stacking which allows for the RFC stated "premium services".
Cheers,
-Michael Cohen
-----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 12:04 PM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks
I guess you answered your own question: "And I'm not sure what faster switching/routing has to do with MPLS:)"
As far as CEF and such goes, I couldn't disagree with that (as I was not comparing MPLS to other optimized forwarding techniques), however, MPLS is not a vendor-proprietary forwarding mechanism, which means that I can deploy it worldwide, or state-wide, whatever the case may be, in my network and have the benefit of using only ONE protocol with MPLS-enabled/aware routers/switches. A definate plus over the other proprietary fast switching techniques you mentioned.
Your last statement indicates "added services" have nothing to do with
the fast switching processing of MPLS, when in fact these services depend upon the faster delivery of the non-proprietary fast switching of MPLS. As quoted from the rfc:
"This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services."
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 11:20 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks
I still have to disagree that MPLS results in faster switching/routing in modern service provider networks. Modern vendor caching mechanisms are just as fast if not faster than MPLS processing. With the small overhead of MPLS labels and LDP I highly doubt that you're getting any performance increase over Cisco's CEF or Juniper's FPC architecture. I also doubt that speed is a benefit that service providers consider when deciding whether or not they want to implement MPLS. Added services that run on top of MPLS like VPNs, traffic engineering, and fast rerouting capabilities (all mentioned in
original post) are more likely the benefits considered. Perhaps when label switching was first being marketed (Ipsilon and Cisco in 1996) there were some speed benefits but now I think it's the services that use MPLS
All: I've been consulting MPLS solutions for service providers here in Asia. The main reason for running MPLS is traffic engineering. The main reason for desiring traffic engineering is because of the hyper-aggregation problem with the routing protocols. I talked to one provider who was obviously stressed and showed emotion when addressing this problem. Basically, they appeared just shy of desperate. You also have more flexibility separating the data and control planes. Remember that the control plane (RSVP, IP Telephony, IBGP sessions across the network core) follows the same best path(s) as the data plan. Fortunately for RSVP, you can strict and loose route to avoid this problem. I assume this is important because RSVP is how you signal the LSP's to solve the original problem! You can engineer each plane and classify flows into Forward Equivalency Classes (FECs). Think of the example I will post below as the endpoints to the L2 VPN going towards the Virtual Circuit (VC FEC). WARNING: Traffic Engineering can create more problems than it solves if you do not engineer correctly. Data collection BEFORE traffic engineering is essential. You should enter step 2 (configuring TE) with full understanding of your network. How do I apply this in a metro access network? Before we talk about MPLS, let's talk about a metro network that uses Super VLAN Aggregation (not standardized, Foundry and Extreme support as well as other vendors who I apologize for not mentioning if they do. If you work for one of these vendors please let me know so I can tell my customers who our competitors are :-). You can traffic engineer using 802.1s STP groupings, but you have scalability limitations (12 bits of VLAN ID in .1q tag) of 4096x4096. This is an excellent solution with all of the other enhancements such as 802.1w (Rapid Spanning Tree for failover times of less than 5 seconds and as fast as 50ms). Additionally, vendor proprietary standards help out such as Foundry's Super Span for segregating STP domains and tunneling BPDU's to arrive where they should. Now let's talk about MPLS. Most of you are smarter than I and familiar with Cisco IOS. Foundry uses a similar flavor of the CLI (like different UNIX versions :-) I'll drop a config on how you can engineer 4 VLANS through your network. The users think they are on the same Ethernet wire (Ethernet Psuedo Wire End-to-End Encapsulation). One LSP transmits and one LSP receives (full duplex). The technology involved is simple Layer2 VPN Draft Martini. It is only point to point and this is not the forum to discuss the ever evolving standards that are competing; however, the Martini drafts are mature and I believe ready to reach informational RFC status very soon. I don't believe the market (NANOG folks reading this message for example) wants the complexity of running BGP on L2 or L3 VPNs. This is why you won't find too much support for the new draft Kompella (not to be confused with the developing VPLS draft VKompella). Juniper showed a configuration slide of this at MPLS Japan last week (original draft recently released and not mature "00" with no revisions and missing information). I would request someone from Juniper post a configuration to this list showing my same example with Kompella support for complexity comparison. If I were a Juniper customer already running L3 VPN I would take a serious look at this. It reduces the complexity a bit, but not enough for my liking. Everyone agrees that separating MAC address learning is essential for solving MAC address scalability requirements. Targeted LDP sessions appear to be a lot less complex than BGP and we may see some solutions arrive soon. The Martini drafts got the LDP targeted sessions covered nicely. I'm an SE who reads NANOG to help better understand my customers' problems. I'm not a developer and I'm not caught up in the whirlwind going on in the MPLS WG or back in San Jose. I'll leave that task to smarter folks with better access to Starbucks. I also encourage you to take a look at using Super VLAN technology with an MPLS core to solve scalability problems when you want the best of both words. Example Terminology: LSP: Label Switched Path that uses the tunnel label. Signaled and setup through RSVP in this example. VLL: Virtual Leased Line that uses the VC label. OSPF-TE: Opaque LSA support. Note that I've configured and I HIGHLY recommend you do this whether you use CSPF or not. "show ip ospf database link opaque" can be an awesome command and I believe it is the same on Cisco IOS. For those of you that have this ability and understanding, you may want to generate these LSA's regardless of your plans for MPLS. Hot standby paths: Pre-signaled RSVP paths for faster failover in this example. My example also uses statically defined VC label definitions. This brings up the VC as soon as the LSP route comes up (show mpls route) and reduces convergence time by eliminating the need for targeted LDP overhead. NOTE: Consider this L2 VPN complexity that can be eliminated if you think it is too complex to manage. These are the values you see after the vll-peer statements. I will demonstrate the mixing and matching of tagged 802.1Q lines as well. We have a topology as follows: B A_/ \_D \ / C Please don't give me any feedback of "Why" I would run MPLS on such a simple network. It is meant for simplicity only. Note that these are working configs for the folks that knock MPLS for configuration complexity. I cannot speak for other vendors. You would also need our latest and greatest code (7.5.00) which is not available to our non beta customers until next week. I've included configs for B, but not C. I'm sure you can all figure out C. -------------------------------------------------------- hostname A router mpls policy traffic-eng ospf mpls-interface p2/1 mpls-interface p2/2 path B-to-D strict 192.168.10.2 strict 192.168.20.1 path C-to-D strict 192.168.30.2 strict 192.168.40.1 lsp LSP1 to 192.168.50.1 primary B-to-D secondary C-to-D standby enable lsp LSP2 to 192.168.50.2 primary B-to-D secondary C-to-D standby enable lsp LSP3 to 192.168.50.3 primary B-to-D secondary C-to-D standby enable lsp LSP4 to 192.168.50.4 primary C-to-D secondary B-to-D standby enable vll VLAN10 10 vll-peer 192.168.50.1 800001 900001 vlan 10 tagged e 1/1 vll VLAN20 20 vll-peer 192.168.50.2 800002 900002 vlan 20 tagged e 1/1 vll VLAN30 30 vll-peer 192.168.50.3 800003 900003 vlan 30 tagged e 1/1 vll VLAN40 40 vll-peer 192.168.50.4 800004 900004 vlan 40 tagged e 1/1 ! boot sys slot1 N2M07500.bin route-only router ospf area 0 ! interface loopback 1 ip address 192.168.5.1 255.255.255.255 ip ospf area 0 interface loopback 2 ip address 192.168.5.2 255.255.255.255 ip ospf area 0 interface loopback 3 ip address 192.168.5.3 255.255.255.255 ip ospf area 0 interface loopback 4 ip address 192.168.5.4 255.255.255.255 ip ospf area 0 ! interface ethernet 1/1 enable ! interface pos 2/1 enable ip address 192.168.10.1 255.255.255.0 ip ospf area 0 ! interface pos 2/2 enable ip address 192.168.30.1 255.255.255.0 ip ospf area 0 ! ! ! ! ! end -------------------------------------------- hostname D router mpls policy traffic-eng ospf mpls-interface p2/1 mpls-interface p2/2 path B-to-A strict 192.168.20.2 strict 192.168.10.1 path C-to-A strict 192.168.40.2 strict 192.168.30.1 lsp LSP1 to 192.168.5.1 primary B-to-A secondary C-to-A standby enable lsp LSP2 to 192.168.5.2 primary B-to-A secondary C-to-A standby enable lsp LSP3 to 192.168.5.3 primary B-to-A secondary C-to-A standby enable lsp LSP4 to 192.168.5.4 primary C-to-A secondary B-to-A standby enable vll VLAN10 10 vll-peer 192.168.5.1 900001 800001 untagged e 1/1 vll VLAN20 20 vll-peer 192.168.5.2 900002 800002 untagged e 1/2 vll VLAN30 30 vll-peer 192.168.5.3 900003 800003 untagged e 1/3 vll VLAN40 40 vll-peer 192.168.5.4 900004 800004 untagged e 1/4 ! boot sys slot1 N2M07500.bin route-only router ospf area 0 ! interface loopback 1 ip address 192.168.5.1 255.255.255.255 ip ospf area 0 interface loopback 2 ip address 192.168.5.2 255.255.255.255 ip ospf area 0 interface loopback 3 ip address 192.168.5.3 255.255.255.255 ip ospf area 0 interface loopback 4 ip address 192.168.5.4 255.255.255.255 ip ospf area 0 ! interface ethernet 1/1 enable ! interface pos 2/1 port-name NI800_D_POS_3/1 enable ip address 192.168.40.1 255.255.255.0 ip ospf area 0 ! interface pos 2/2 port-name NI800_D_POS_3/2 enable ip address 192.168.20.1 255.255.255.0 ip ospf area 0! ! ! ! ! end ------------------------------------------------- hostname C router mpls policy admin-group OSPF-Primary-Link 2 traffic-eng ospf mpls-interface p6/1 admin-group 2 mpls-interface p6/2 admin-group 2 ! boot sys slot1 N2M07500B5.bin route-only router ospf area 0 ! interface pos 6/1 enable ip address 192.168.40.2 255.255.255.0 ip ospf area 0 ! interface pos 6/2 enable ip address 192.168.30.2 255.255.255.0 ip ospf area 0 ! ! ! ! ! end Gary Blankenship Foundry Networks Systems Engineer - Japan CCIE #5009 garyb@foundrynet.com www.foundrynet.com PC Magazine Selects Foundry FastIron 4802 as Best High End Ethernet Switch: http://www.pcmag.com/article/0,2997,s%253D25109%2526a%253D17629,00.asp their this provide the the that
are the major benefit.
-Michael Cohen
-----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:59 AM To: 'mcohen@thrupoint.net'; 'nanog@merit.edu' Subject: RE: MPLS in metro access networks
soooo...Label switching assigns labels to packet headers which results in less time and processing looking up routes, and instead relies upon a label index for forwarding decisions? Hence my statement "faster switching/routing and less processing":)
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:56 AM To: Quibell, Marc Subject: RE: MPLS in metro access networks
I hope so:)
-----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:46 AM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks
Are we talking about Multiprotocol Label Switching?
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:45 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks
And I'm not sure what faster switching/routing has to do with MPLS:) I believe one of the ideas behind MPLS benefiting metro access networks is using MPLS to deliver layer 2 VPNs across an MPLS enabled core thus simulating leased lines for access clients...but I'm sure somebody will correct me if I'm wrong. There seems to be some hype for Martini draft VPNs and large enterprise customers in metro areas.
Cheers,
-Michael Cohen
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Quibell, Marc Sent: Thursday, November 15, 2001 10:20 AM To: 'srihari varada'; nanog@merit.edu Subject: RE: MPLS in metro access networks
I would think faster switching/routing and less processing would be wanted in any mid-to-large sized network...I'm not sure what load balancing and fault restoration has to do with MPLS....
Marc
-----Original Message----- From: srihari varada [mailto:varada@txc.com] Sent: Thursday, November 15, 2001 10:12 AM To: nanog@merit.edu Subject: MPLS in metro access networks
Hello:
I have heard some stressing the role of MPLS in metro access networks. It is difficult for me to visualize the need for it in them while it is not so difficult to understand the utility (load balancing and fault restoration etc.) of it in the metro backbone networks.
To characterize metro access networks in the context, the following is provided: -- aggregates traffic from residential (arriving via broadband access links such as xDSL, Cable) and business consumers (arriving via broadband access links such as xDSL and high speed links such as Ethernet or SONET) -- funnels aggregated traffic to metro backbone networks for destination
hosts in the local metro region or remote regions across the internet regional and backbone networks. Majority of such access networks are SONET/ATM based (I didn't come across any case of Gig Ethernet. However, I do not preculde it).
Thus, there are two questions: -- Are there known RBOCs/ILECs and CLECs entrenching MPLS in the said network scope? (I do not see many major ILECs in the un-official MPLS service providers list being circulated but it may mean little) -- If so, what motivates them to do so? Any analysis of the driving forces is appreciated.
Regards,
Srihari Varada
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Gary Blankenship Sent: Friday, November 16, 2001 5:34 PM To: nanog@merit.edu Subject: RE: MPLS in metro access networks
Srihari:
I'm going to attempt to answer your original question:
-- If so, what motivates them to do so? Any analysis of the driving forces is appreciated.
All:
I've been consulting MPLS solutions for service providers here in Asia. The main reason for running MPLS is traffic engineering. The main reason for desiring traffic engineering is because of the hyper-aggregation problem with the routing protocols. I talked to one provider who was obviously stressed and showed emotion when addressing this problem. Basically, they appeared just shy of desperate.
You also have more flexibility separating the data and control planes. Remember that the control plane (RSVP, IP Telephony, IBGP sessions across the network core) follows the same best path(s) as the data
Fortunately for RSVP, you can strict and loose route to avoid this problem. I assume this is important because RSVP is how you signal
LSP's to solve the original problem! You can engineer each plane and classify flows into Forward Equivalency Classes (FECs). Think of the example I will post below as the endpoints to the L2 VPN going towards the Virtual Circuit (VC FEC).
WARNING: Traffic Engineering can create more problems than it solves if you do not engineer correctly. Data collection BEFORE traffic engineering is essential. You should enter step 2 (configuring TE) with full understanding of your network.
How do I apply this in a metro access network? Before we talk about MPLS, let's talk about a metro network that uses Super VLAN Aggregation (not standardized, Foundry and Extreme support as well as other vendors who I apologize for not mentioning if they do. If you work for one of these vendors please let me know so I can tell my customers who our competitors are :-). You can traffic engineer using 802.1s STP groupings, but you have scalability limitations (12 bits of VLAN ID in .1q tag) of 4096x4096. This is an excellent solution with all of the other enhancements such as 802.1w (Rapid Spanning Tree for failover times of less than 5 seconds and as fast as 50ms). Additionally, vendor proprietary standards help out such as Foundry's Super Span for segregating STP domains and tunneling BPDU's to arrive where they should.
Now let's talk about MPLS. Most of you are smarter than I and familiar with Cisco IOS. Foundry uses a similar flavor of the CLI (like different UNIX versions :-) I'll drop a config on how you can engineer 4 VLANS through your network.
The users think they are on the same Ethernet wire (Ethernet Psuedo Wire End-to-End Encapsulation). One LSP transmits and one LSP receives (full duplex). The technology involved is simple Layer2 VPN Draft Martini. It is only point to point and this is not the forum to discuss the ever evolving standards that are competing; however, the Martini drafts are mature and I believe ready to reach informational RFC status very soon.
I don't believe the market (NANOG folks reading this message for example) wants the complexity of running BGP on L2 or L3 VPNs. This is why you won't find too much support for the new draft Kompella (not to be confused with the developing VPLS draft VKompella). Juniper showed a configuration slide of this at MPLS Japan last week (original draft recently released and not mature "00" with no revisions and missing information). I would request someone from Juniper post a configuration to this list showing my same example with Kompella support for complexity comparison. If I were a Juniper customer already running L3 VPN I would take a serious look at this. It reduces the complexity a bit, but not enough for my liking.
Everyone agrees that separating MAC address learning is essential for solving MAC address scalability requirements. Targeted LDP sessions appear to be a lot less complex than BGP and we may see some solutions arrive soon. The Martini drafts got the LDP targeted sessions covered nicely. I'm an SE who reads NANOG to help better understand my customers' problems. I'm not a developer and I'm not caught up in the whirlwind going on in the MPLS WG or back in San Jose. I'll leave
task to smarter folks with better access to Starbucks.
I also encourage you to take a look at using Super VLAN technology with an MPLS core to solve scalability problems when you want the best of both words.
Example Terminology:
LSP: Label Switched Path that uses the tunnel label. Signaled and setup through RSVP in this example.
VLL: Virtual Leased Line that uses the VC label.
OSPF-TE: Opaque LSA support. Note that I've configured and I HIGHLY recommend you do this whether you use CSPF or not. "show ip ospf database link opaque" can be an awesome command and I believe it is
same on Cisco IOS. For those of you that have this ability and understanding, you may want to generate these LSA's regardless of your plans for MPLS.
Hot standby paths: Pre-signaled RSVP paths for faster failover in
example.
My example also uses statically defined VC label definitions. This brings up the VC as soon as the LSP route comes up (show mpls route) and reduces convergence time by eliminating the need for targeted LDP overhead. NOTE: Consider this L2 VPN complexity that can be eliminated if you think it is too complex to manage. These are the values you see after the vll-peer statements.
I will demonstrate the mixing and matching of tagged 802.1Q lines as well.
We have a topology as follows:
B A_/ \_D \ / C
Please don't give me any feedback of "Why" I would run MPLS on such a simple network. It is meant for simplicity only. Note that these are working configs for the folks that knock MPLS for configuration complexity. I cannot speak for other vendors. You would also need our latest and greatest code (7.5.00) which is not available to our non beta customers until next week. I've included configs for B, but not C. I'm sure you can all figure out C.
-------------------------------------------------------- hostname A
router mpls policy traffic-eng ospf
mpls-interface p2/1 mpls-interface p2/2
path B-to-D strict 192.168.10.2 strict 192.168.20.1 path C-to-D strict 192.168.30.2 strict 192.168.40.1
lsp LSP1 to 192.168.50.1 primary B-to-D secondary C-to-D standby enable
lsp LSP2 to 192.168.50.2 primary B-to-D secondary C-to-D standby enable
lsp LSP3 to 192.168.50.3 primary B-to-D secondary C-to-D standby enable
lsp LSP4 to 192.168.50.4 primary C-to-D secondary B-to-D standby enable
vll VLAN10 10 vll-peer 192.168.50.1 800001 900001 vlan 10 tagged e 1/1 vll VLAN20 20 vll-peer 192.168.50.2 800002 900002 vlan 20 tagged e 1/1 vll VLAN30 30 vll-peer 192.168.50.3 800003 900003 vlan 30 tagged e 1/1 vll VLAN40 40 vll-peer 192.168.50.4 800004 900004 vlan 40 tagged e 1/1 ! boot sys slot1 N2M07500.bin route-only router ospf area 0 ! interface loopback 1 ip address 192.168.5.1 255.255.255.255 ip ospf area 0
interface loopback 2 ip address 192.168.5.2 255.255.255.255 ip ospf area 0
interface loopback 3 ip address 192.168.5.3 255.255.255.255 ip ospf area 0
interface loopback 4 ip address 192.168.5.4 255.255.255.255 ip ospf area 0 ! interface ethernet 1/1 enable ! interface pos 2/1 enable ip address 192.168.10.1 255.255.255.0 ip ospf area 0 ! interface pos 2/2 enable ip address 192.168.30.1 255.255.255.0 ip ospf area 0 ! ! ! ! ! end
--------------------------------------------
hostname D router mpls policy traffic-eng ospf
mpls-interface p2/1 mpls-interface p2/2
path B-to-A strict 192.168.20.2 strict 192.168.10.1 path C-to-A strict 192.168.40.2 strict 192.168.30.1
lsp LSP1 to 192.168.5.1 primary B-to-A secondary C-to-A standby enable
lsp LSP2 to 192.168.5.2 primary B-to-A secondary C-to-A standby enable
lsp LSP3 to 192.168.5.3 primary B-to-A secondary C-to-A standby enable
lsp LSP4 to 192.168.5.4 primary C-to-A secondary B-to-A standby enable
vll VLAN10 10 vll-peer 192.168.5.1 900001 800001 untagged e 1/1 vll VLAN20 20 vll-peer 192.168.5.2 900002 800002 untagged e 1/2 vll VLAN30 30 vll-peer 192.168.5.3 900003 800003 untagged e 1/3 vll VLAN40 40 vll-peer 192.168.5.4 900004 800004 untagged e 1/4
! boot sys slot1 N2M07500.bin route-only router ospf area 0 ! interface loopback 1 ip address 192.168.5.1 255.255.255.255 ip ospf area 0
interface loopback 2 ip address 192.168.5.2 255.255.255.255 ip ospf area 0
interface loopback 3 ip address 192.168.5.3 255.255.255.255 ip ospf area 0
interface loopback 4 ip address 192.168.5.4 255.255.255.255 ip ospf area 0 ! interface ethernet 1/1 enable ! interface pos 2/1 port-name NI800_D_POS_3/1 enable ip address 192.168.40.1 255.255.255.0 ip ospf area 0 ! interface pos 2/2 port-name NI800_D_POS_3/2 enable ip address 192.168.20.1 255.255.255.0 ip ospf area 0! ! ! ! ! end
------------------------------------------------- hostname C
router mpls policy admin-group OSPF-Primary-Link 2 traffic-eng ospf
mpls-interface p6/1 admin-group 2 mpls-interface p6/2 admin-group 2
! boot sys slot1 N2M07500B5.bin route-only router ospf area 0 ! interface pos 6/1 enable ip address 192.168.40.2 255.255.255.0 ip ospf area 0 ! interface pos 6/2 enable ip address 192.168.30.2 255.255.255.0 ip ospf area 0 ! ! ! ! ! end
Gary Blankenship Foundry Networks Systems Engineer - Japan CCIE #5009 garyb@foundrynet.com www.foundrynet.com
PC Magazine Selects Foundry FastIron 4802 as Best High End Ethernet Switch: http://www.pcmag.com/article/0,2997,s%253D25109%2526a%253D17629,00.asp
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Michael Cohen Sent: Friday, November 16, 2001 3:45 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks
Maybe I'm getting confused. The original post asked the question "what motivates them" (RBOCs, ILECs, and CLECs) to implement MPLS. You answered that fast switching/routing was a reason. I disagree with this because designing and implementing MPLS just for speed benefits is a bit too cumbersome and complex compared to using local caching mechanisms
Forgive me for the config error on the previous post. Loopbacks on router D should have been X.X.50.X not X.X.5.X. Gary plan. the that the this that
just as fast, if not faster. Saying that using MPLS as an alternative to using local caching mechanisms because of standardization doesn't make sense to me either because the local caching mechanisms are in place regardless. In fact, you can't run MPLS on most vendor hardware without running
proprietary caching (Cisco mandates using CEF before implementing MPLS and Juniper uses it's FPC hardware architecture regardless of MPLS). So to add to my point, there is no speed benefit in running MPLS if you are already using modern caching techniques, which most service providers interested in MPLS are already doing.
To respond to your second point regarding using added services I agree completely that these services require MPLS labels to work. However,
still has nothing to do with speed benefits. You say "these services depend upon the faster delivery" of MPLS but the RFC doesn't mention speed at all. It just says "This approach uses MPLS running in the backbone to
premium services". Any MPLS added service uses label stacking which allows for the RFC stated "premium services".
Cheers,
-Michael Cohen
-----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 12:04 PM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks
I guess you answered your own question: "And I'm not sure what faster switching/routing has to do with MPLS:)"
As far as CEF and such goes, I couldn't disagree with that (as I was not comparing MPLS to other optimized forwarding techniques), however, MPLS is not a vendor-proprietary forwarding mechanism, which means that I can deploy it worldwide, or state-wide, whatever the case may be, in my network and have the benefit of using only ONE protocol with MPLS-enabled/aware routers/switches. A definate plus over the other proprietary fast switching techniques you mentioned.
Your last statement indicates "added services" have nothing to do with
the fast switching processing of MPLS, when in fact these services depend upon the faster delivery of the non-proprietary fast switching of MPLS. As quoted from the rfc:
"This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services."
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 11:20 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks
I still have to disagree that MPLS results in faster switching/routing in modern service provider networks. Modern vendor caching mechanisms are just as fast if not faster than MPLS processing. With the small overhead of MPLS labels and LDP I highly doubt that you're getting any performance increase over Cisco's CEF or Juniper's FPC architecture. I also doubt that speed is a benefit that service providers consider when deciding whether or not they want to implement MPLS. Added services that run on top of MPLS like VPNs, traffic engineering, and fast rerouting capabilities (all mentioned in
original post) are more likely the benefits considered. Perhaps when label switching was first being marketed (Ipsilon and Cisco in 1996) there were some speed benefits but now I think it's the services that use MPLS
are their this provide the the that
are the major benefit.
-Michael Cohen
-----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:59 AM To: 'mcohen@thrupoint.net'; 'nanog@merit.edu' Subject: RE: MPLS in metro access networks
soooo...Label switching assigns labels to packet headers which results in less time and processing looking up routes, and instead relies upon a label index for forwarding decisions? Hence my statement "faster switching/routing and less processing":)
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:56 AM To: Quibell, Marc Subject: RE: MPLS in metro access networks
I hope so:)
-----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:46 AM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks
Are we talking about Multiprotocol Label Switching?
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:45 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks
And I'm not sure what faster switching/routing has to do with MPLS:) I believe one of the ideas behind MPLS benefiting metro access networks is using MPLS to deliver layer 2 VPNs across an MPLS enabled core thus simulating leased lines for access clients...but I'm sure somebody will correct me if I'm wrong. There seems to be some hype for Martini draft VPNs and large enterprise customers in metro areas.
Cheers,
-Michael Cohen
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Quibell, Marc Sent: Thursday, November 15, 2001 10:20 AM To: 'srihari varada'; nanog@merit.edu Subject: RE: MPLS in metro access networks
I would think faster switching/routing and less processing would be wanted in any mid-to-large sized network...I'm not sure what load balancing and fault restoration has to do with MPLS....
Marc
-----Original Message----- From: srihari varada [mailto:varada@txc.com] Sent: Thursday, November 15, 2001 10:12 AM To: nanog@merit.edu Subject: MPLS in metro access networks
Hello:
I have heard some stressing the role of MPLS in metro access networks. It is difficult for me to visualize the need for it in them while it is not so difficult to understand the utility (load balancing and fault restoration etc.) of it in the metro backbone networks.
To characterize metro access networks in the context, the following is provided: -- aggregates traffic from residential (arriving via broadband access links such as xDSL, Cable) and business consumers (arriving via broadband access links such as xDSL and high speed links such as Ethernet or SONET) -- funnels aggregated traffic to metro backbone networks for destination
hosts in the local metro region or remote regions across the internet regional and backbone networks. Majority of such access networks are SONET/ATM based (I didn't come across any case of Gig Ethernet. However, I do not preculde it).
Thus, there are two questions: -- Are there known RBOCs/ILECs and CLECs entrenching MPLS in the said network scope? (I do not see many major ILECs in the un-official MPLS service providers list being circulated but it may mean little) -- If so, what motivates them to do so? Any analysis of the driving forces is appreciated.
Regards,
Srihari Varada
The only problem with this approach is the idea that you can divource a standards based approach like MPLS with the vendor specific implimentation of switching methodologies. On the Cisco platform, for example, MPLS is deeply tied into CEF, for somewhat logical reasons - Cisco saw no need to reinvent the wheel, and didn't want to go down the path of a new forwarding technology. The platforms are STILL using proprietary switching methods - they always will, as it is a distiguisher. You seem to imply that if you use MPLS, you won't be using other methods of distributed or fast switching on your routers. This simply is not the case. On Cisco's you will still use CEF, and on Junipers you will use ASIC-based FPC switching. MPLS is not useful in and of itself as a switching mechanism. However, it is useful for TE, VPNs, etc. If you enable MPLS on your network to get "better performance", "faster speeds", or a "more reliable core", you will be disappointed in the end, as the performance is the same, speed is the same, and reliability is lower due to immature code. - Daniel Golding -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Quibell, Marc Sent: Thursday, November 15, 2001 1:04 PM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks I guess you answered your own question: "And I'm not sure what faster switching/routing has to do with MPLS:)" As far as CEF and such goes, I couldn't disagree with that (as I was not comparing MPLS to other optimized forwarding techniques), however, MPLS is not a vendor-proprietary forwarding mechanism, which means that I can deploy it worldwide, or state-wide, whatever the case may be, in my network and have the benefit of using only ONE protocol with MPLS-enabled/aware routers/switches. A definate plus over the other proprietary fast switching techniques you mentioned. Your last statement indicates "added services" have nothing to do with the the fast switching processing of MPLS, when in fact these services depend upon the faster delivery of the non-proprietary fast switching of MPLS. As quoted from the rfc: "This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services." Marc -----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 11:20 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks I still have to disagree that MPLS results in faster switching/routing in modern service provider networks. Modern vendor caching mechanisms are just as fast if not faster than MPLS processing. With the small overhead of MPLS labels and LDP I highly doubt that you're getting any performance increase over Cisco's CEF or Juniper's FPC architecture. I also doubt that speed is a benefit that service providers consider when deciding whether or not they want to implement MPLS. Added services that run on top of MPLS like VPNs, traffic engineering, and fast rerouting capabilities (all mentioned in the original post) are more likely the benefits considered. Perhaps when label switching was first being marketed (Ipsilon and Cisco in 1996) there were some speed benefits but now I think it's the services that use MPLS that are the major benefit. -Michael Cohen -----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:59 AM To: 'mcohen@thrupoint.net'; 'nanog@merit.edu' Subject: RE: MPLS in metro access networks soooo...Label switching assigns labels to packet headers which results in less time and processing looking up routes, and instead relies upon a label index for forwarding decisions? Hence my statement "faster switching/routing and less processing":) Marc -----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:56 AM To: Quibell, Marc Subject: RE: MPLS in metro access networks I hope so:) -----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:46 AM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks Are we talking about Multiprotocol Label Switching? Marc -----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:45 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks And I'm not sure what faster switching/routing has to do with MPLS:) I believe one of the ideas behind MPLS benefiting metro access networks is using MPLS to deliver layer 2 VPNs across an MPLS enabled core thus simulating leased lines for access clients...but I'm sure somebody will correct me if I'm wrong. There seems to be some hype for Martini draft VPNs and large enterprise customers in metro areas. Cheers, -Michael Cohen -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Quibell, Marc Sent: Thursday, November 15, 2001 10:20 AM To: 'srihari varada'; nanog@merit.edu Subject: RE: MPLS in metro access networks I would think faster switching/routing and less processing would be wanted in any mid-to-large sized network...I'm not sure what load balancing and fault restoration has to do with MPLS.... Marc -----Original Message----- From: srihari varada [mailto:varada@txc.com] Sent: Thursday, November 15, 2001 10:12 AM To: nanog@merit.edu Subject: MPLS in metro access networks Hello: I have heard some stressing the role of MPLS in metro access networks. It is difficult for me to visualize the need for it in them while it is not so difficult to understand the utility (load balancing and fault restoration etc.) of it in the metro backbone networks. To characterize metro access networks in the context, the following is provided: -- aggregates traffic from residential (arriving via broadband access links such as xDSL, Cable) and business consumers (arriving via broadband access links such as xDSL and high speed links such as Ethernet or SONET) -- funnels aggregated traffic to metro backbone networks for destination hosts in the local metro region or remote regions across the internet regional and backbone networks. Majority of such access networks are SONET/ATM based (I didn't come across any case of Gig Ethernet. However, I do not preculde it). Thus, there are two questions: -- Are there known RBOCs/ILECs and CLECs entrenching MPLS in the said network scope? (I do not see many major ILECs in the un-official MPLS service providers list being circulated but it may mean little) -- If so, what motivates them to do so? Any analysis of the driving forces is appreciated. Regards, Srihari Varada
MPLS is not useful in and of itself as a switching mechanism. However, it is useful for TE, VPNs, etc. If you enable MPLS on your network to get "better performance", "faster speeds", or a "more reliable core", you will be disappointed in the end, as the performance is the same, speed is the same, and reliability is lower due to immature code.
How old is your information? The company I'm working for has been using MPLS for some 2 years now (maybe more, maybe less, I forget). We have found the code to be quite stable, although that speaks as much to our vendors improved QA as it does to our internal QA and testing that takes place months before deployment. MPLS-TE is definitely a valuable feature. It was worth it for us to deploy it back in '99, and it's worth it now. MPLS-based VPN's are interesting in their own right. I would not consider MPLS to be bleeding edge anymore...and for us, it doesn't really feel cutting edge anymore either. It's the newer features still in the standards process that might be dangerous to deploy at this stage, but that's what labs are for (that would be an actual lab, not the "production lab" :-). That being said, I would love to see some quantifiable data showing the differences in switching latencies between labels and packets. %age increase in efficient use of network capacity will of course depend on your backbone design. Reliability, in the end, has more to do with organization processes for engineering and operating your network than the quality of a vendor's latest GA release of code. Dave
- Daniel Golding
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Quibell, Marc Sent: Thursday, November 15, 2001 1:04 PM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks
I guess you answered your own question: "And I'm not sure what faster switching/routing has to do with MPLS:)"
As far as CEF and such goes, I couldn't disagree with that (as I was not comparing MPLS to other optimized forwarding techniques), however, MPLS is not a vendor-proprietary forwarding mechanism, which means that I can deploy it worldwide, or state-wide, whatever the case may be, in my network and have the benefit of using only ONE protocol with MPLS-enabled/aware routers/switches. A definate plus over the other proprietary fast switching techniques you mentioned.
Your last statement indicates "added services" have nothing to do with the the fast switching processing of MPLS, when in fact these services depend upon the faster delivery of the non-proprietary fast switching of MPLS. As quoted from the rfc:
"This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services."
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 11:20 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks
I still have to disagree that MPLS results in faster switching/routing in modern service provider networks. Modern vendor caching mechanisms are just as fast if not faster than MPLS processing. With the small overhead of MPLS labels and LDP I highly doubt that you're getting any performance increase over Cisco's CEF or Juniper's FPC architecture. I also doubt that speed is a benefit that service providers consider when deciding whether or not they want to implement MPLS. Added services that run on top of MPLS like VPNs, traffic engineering, and fast rerouting capabilities (all mentioned in the original post) are more likely the benefits considered. Perhaps when label switching was first being marketed (Ipsilon and Cisco in 1996) there were some speed benefits but now I think it's the services that use MPLS that are the major benefit.
-Michael Cohen
-----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:59 AM To: 'mcohen@thrupoint.net'; 'nanog@merit.edu' Subject: RE: MPLS in metro access networks
soooo...Label switching assigns labels to packet headers which results in less time and processing looking up routes, and instead relies upon a label index for forwarding decisions? Hence my statement "faster switching/routing and less processing":)
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:56 AM To: Quibell, Marc Subject: RE: MPLS in metro access networks
I hope so:)
-----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:46 AM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks
Are we talking about Multiprotocol Label Switching?
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:45 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks
And I'm not sure what faster switching/routing has to do with MPLS:) I believe one of the ideas behind MPLS benefiting metro access networks is using MPLS to deliver layer 2 VPNs across an MPLS enabled core thus simulating leased lines for access clients...but I'm sure somebody will correct me if I'm wrong. There seems to be some hype for Martini draft VPNs and large enterprise customers in metro areas.
Cheers,
-Michael Cohen
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Quibell, Marc Sent: Thursday, November 15, 2001 10:20 AM To: 'srihari varada'; nanog@merit.edu Subject: RE: MPLS in metro access networks
I would think faster switching/routing and less processing would be wanted in any mid-to-large sized network...I'm not sure what load balancing and fault restoration has to do with MPLS....
Marc
-----Original Message----- From: srihari varada [mailto:varada@txc.com] Sent: Thursday, November 15, 2001 10:12 AM To: nanog@merit.edu Subject: MPLS in metro access networks
Hello:
I have heard some stressing the role of MPLS in metro access networks. It is difficult for me to visualize the need for it in them while it is not so difficult to understand the utility (load balancing and fault restoration etc.) of it in the metro backbone networks.
To characterize metro access networks in the context, the following is provided: -- aggregates traffic from residential (arriving via broadband access links such as xDSL, Cable) and business consumers (arriving via broadband access links such as xDSL and high speed links such as Ethernet or SONET) -- funnels aggregated traffic to metro backbone networks for destination
hosts in the local metro region or remote regions across the internet regional and backbone networks. Majority of such access networks are SONET/ATM based (I didn't come across any case of Gig Ethernet. However, I do not preculde it).
Thus, there are two questions: -- Are there known RBOCs/ILECs and CLECs entrenching MPLS in the said network scope? (I do not see many major ILECs in the un-official MPLS service providers list being circulated but it may mean little) -- If so, what motivates them to do so? Any analysis of the driving forces is appreciated.
Regards,
Srihari Varada
-- Dave Siegel HOME 520-877-2593 dave at siegelie dot com WORK 520-877-2628 dsiegel at gblx dot net Director, IP Engineering, Global Crossing
On Wed, Nov 28, 2001 at 05:27:15PM -0700, Dave Siegel wrote:
That being said, I would love to see some quantifiable data showing the differences in switching latencies between labels and packets. %age increase
If there is a difference in latency between MPLS and IP switching you need to beat your vendor, and/or change vendors. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Wed, Nov 28, 2001 at 08:17:30PM -0500, Leo Bicknell reportedly typed:
On Wed, Nov 28, 2001 at 05:27:15PM -0700, Dave Siegel wrote:
That being said, I would love to see some quantifiable data showing the differences in switching latencies between labels and packets. %age increase
If there is a difference in latency between MPLS and IP switching you need to beat your vendor, and/or change vendors.
If there is a difference, I would expect it to be in the order of low, single-digit microseconds. -- Dave Siegel HOME 520-877-2593 dave at siegelie dot com WORK 520-877-2628 dsiegel at gblx dot net Director, IP Engineering, Global Crossing
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave, Are you suggesting that MPLS is truly a faster switching paradigm across a large network? There is basically no meaurable latency difference in MPLS networks, unless you have avoided congestion by using TE. As far as reliability - your milage may vary. MPLS-TE, which you mention, is certainly one of the various vendors' more stable MPLS features. However, just in the past 6 months, major vendors have shipped several versions of code, (including in the "stable" code trains), with major MPLS issues - many of which are of the "drop packets on the floor, because we don't know what to do with them" variety. I don't think anyone is slamming MPLS or it's implementations just because their might be a bug in "a vendor's latest GA release of code". MPLS is a complexity added onto already complex code. However, the proponents of MPLS based networks stress things like it's reliability, speed and simplicity, over existing, pure IP network designs. My point, is that it is certain not faster, not any simpler, and, for many, has been considerably less reliable. I reiterate that the point of implimenting MPLS is to be able to provide the services it enables (of which, TE is a great example, along with VPNs). Of course, different levels of perceived reliability may be due to different depths of MPLS implimentation. A design consistint of fully meshed, explicit TE tunnels would probably be pretty reliable, by this point. A network with many L2VPNs and RFC2547 VPNs running over LSPs instantiated by LDP, might be less so, depending on the platform. - - Daniel Golding
-----Original Message----- From: Dave Siegel [mailto:dave@siegelie.com] Sent: Wednesday, November 28, 2001 7:27 PM To: Daniel Golding Cc: Quibell, Marc; mcohen@thrupoint.net; nanog@merit.edu Subject: Re: MPLS in metro access networks
MPLS is not useful in and of itself as a switching mechanism. However, it is useful for TE, VPNs, etc. If you enable MPLS on your network to get "better performance", "faster speeds", or a "more reliable core", you will be disappointed in the end, as the performance is the same, speed is the same, and reliability is lower due to immature code.
How old is your information?
The company I'm working for has been using MPLS for some 2 years now (maybe more, maybe less, I forget). We have found the code to be quite stable, although that speaks as much to our vendors improved QA as it does to our internal QA and testing that takes place months before deployment.
MPLS-TE is definitely a valuable feature. It was worth it for us to deploy it back in '99, and it's worth it now. MPLS-based VPN's are interesting in their own right.
I would not consider MPLS to be bleeding edge anymore...and for us, it doesn't really feel cutting edge anymore either. It's the newer features still in the standards process that might be dangerous to deploy at this stage, but that's what labs are for (that would be an actual lab, not the "production lab" :-).
That being said, I would love to see some quantifiable data showing the differences in switching latencies between labels and packets. %age increase in efficient use of network capacity will of course depend on your backbone design. Reliability, in the end, has more to do with organization processes for engineering and operating your network than the quality of a vendor's latest GA release of code.
Dave
- Daniel Golding
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Quibell, Marc Sent: Thursday, November 15, 2001 1:04 PM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks
I guess you answered your own question: "And I'm not sure what faster switching/routing has to do with MPLS:)"
As far as CEF and such goes, I couldn't disagree with that (as I was not comparing MPLS to other optimized forwarding techniques), however, MPLS is not a vendor-proprietary forwarding mechanism, which means that I can deploy it worldwide, or state-wide, whatever the case may be, in my network and have the benefit of using only ONE protocol with MPLS-enabled/aware routers/switches. A definate plus over the other proprietary fast switching techniques you mentioned.
Your last statement indicates "added services" have nothing to do with the the fast switching processing of MPLS, when in fact these services depend upon the faster delivery of the non-proprietary fast switching of MPLS. As quoted from the rfc:
"This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services."
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 11:20 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks
I still have to disagree that MPLS results in faster switching/routing in modern service provider networks. Modern vendor caching mechanisms are just as fast if not faster than MPLS processing. With the small overhead of MPLS labels and LDP I highly doubt that you're getting any performance increase over Cisco's CEF or Juniper's FPC architecture. I also doubt that speed is a benefit that service providers consider when deciding whether or not they want to implement MPLS. Added services that run on top of MPLS like VPNs, traffic engineering, and fast rerouting capabilities (all mentioned in the original post) are more likely the benefits considered. Perhaps when label switching was first being marketed (Ipsilon and Cisco in 1996) there were some speed benefits but now I think it's the services that use MPLS that are the major benefit.
-Michael Cohen
-----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:59 AM To: 'mcohen@thrupoint.net'; 'nanog@merit.edu' Subject: RE: MPLS in metro access networks
soooo...Label switching assigns labels to packet headers which results in less time and processing looking up routes, and instead relies upon a label index for forwarding decisions? Hence my statement "faster switching/routing and less processing":)
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:56 AM To: Quibell, Marc Subject: RE: MPLS in metro access networks
I hope so:)
-----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:46 AM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks
Are we talking about Multiprotocol Label Switching?
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:45 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks
And I'm not sure what faster switching/routing has to do with MPLS:) I believe one of the ideas behind MPLS benefiting metro access networks is using MPLS to deliver layer 2 VPNs across an MPLS enabled core thus simulating leased lines for access clients...but I'm sure somebody will correct me if I'm wrong. There seems to be some hype for Martini draft VPNs and large enterprise customers in metro areas.
Cheers,
-Michael Cohen
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Quibell, Marc Sent: Thursday, November 15, 2001 10:20 AM To: 'srihari varada'; nanog@merit.edu Subject: RE: MPLS in metro access networks
I would think faster switching/routing and less processing would be wanted in any mid-to-large sized network...I'm not sure what load balancing and fault restoration has to do with MPLS....
Marc
-----Original Message----- From: srihari varada [mailto:varada@txc.com] Sent: Thursday, November 15, 2001 10:12 AM To: nanog@merit.edu Subject: MPLS in metro access networks
Hello:
I have heard some stressing the role of MPLS in metro access networks. It is difficult for me to visualize the need for it in them while it is not so difficult to understand the utility (load balancing and fault restoration etc.) of it in the metro backbone networks.
To characterize metro access networks in the context, the following is provided: -- aggregates traffic from residential (arriving via broadband access links such as xDSL, Cable) and business consumers (arriving via broadband access links such as xDSL and high speed links such as Ethernet or SONET) -- funnels aggregated traffic to metro backbone networks for destination
hosts in the local metro region or remote regions across the internet regional and backbone networks. Majority of such access networks are SONET/ATM based (I didn't come across any case of Gig Ethernet. However, I do not preculde it).
Thus, there are two questions: -- Are there known RBOCs/ILECs and CLECs entrenching MPLS in the said network scope? (I do not see many major ILECs in the un-official MPLS service providers list being circulated but it may mean little) -- If so, what motivates them to do so? Any analysis of the driving forces is appreciated.
Regards,
Srihari Varada
-- Dave Siegel HOME 520-877-2593 dave at siegelie dot com WORK 520-877-2628 dsiegel at gblx dot net Director, IP Engineering, Global Crossing
-----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBPAZoQzIDUnFt7YpmEQKCigCg6oW9MYeLF9dihkU96pS0nAmo2BkAn17O xRDtkoYKmAHxWq1d9ei85Lq5 =8tdw -----END PGP SIGNATURE-----
However, the proponents of MPLS based networks stress things like it's reliability, speed and simplicity, over existing, pure IP network designs.
We do? Not all of us...:) Reliability? I've never heard claims that MPLS is any more or less reliable than IP. Certainly there's fast reroute mechanisms so that a failure can be worked around pretty quickly, but we're talking about a failure at a lower level (link failure) or a box/LC failure (crash). The MPLS software implementation from a given vendor should be as reliable as the IP software; there's nothing fundamentally different in MPLS that makes it easier to code, or inherently bug-free or any of that stuff. Speed? Back in the early days, it was thought that a 20-bit label lookup would be faster than a 32-bit IP DA lookup. With the advent of fast hardware switching, this turns out not to be true. Speaking as I can for only one vendor, I can tell you that anyone from my company who claims MPLS is substantially faster at a switching lookup than IP needs to be beat with a clue stick. It turns out, on some platforms, that imposing a label stack is a wee bit slower than switching an IP packet and that swapping a label is a wee bit faster than switching an IP packet, but "wee bit" means something in the area of a few percent. And this does not apply to all platforms. Simplicitly? Possibly. It might be argued that no longer needing BGP in the core makes your network simpler. But IMHO a BGP-free core in and of itself is not enough of a reason to deploy MPLS. The things I think MPLS buys you are: - traffic engineering for your core - being able to forward traffic down a path other than the one your IGP would select, in a more granular method and less error-prone fashion than other tools to do such (static routes, GRE tunnels, juggling link costs, etc) - ability to carry edge services (L3VPN, L2VPN) across your network. And there's some QoS benefits in here, too, since you have a hierarchical set of labels. MPLS is not the *only* way to do these things, but what it can do has proven useful to lots of people.
My point, is that it is certain not faster, not any simpler, and, for many, has been considerably less reliable. I reiterate that the point of implimenting MPLS is to be able to provide the services it enables (of which, TE is a great example, along with VPNs).
Absolutely. Let me also add that reliability tends to correlate with maturity and deployment, so you'll only see existing implementations get better over time.
Of course, different levels of perceived reliability may be due to different depths of MPLS implimentation. A design consistint of fully meshed, explicit TE tunnels would probably be pretty reliable, by this point. A network with many L2VPNs and RFC2547 VPNs running over LSPs instantiated by LDP, might be less so, depending on the platform.
I think I agree with this. It's not that LDP is inherently any less reliable than TE, but that with FRR one can protect against lower-level failures. I think I prefer "availability" over "reliability" in this context, since that takes into account TE's ability to avoid some congestion that LDP (following the IGP path) can't. But that's just me. eric
- Daniel Golding
-----Original Message----- From: Dave Siegel [mailto:dave@siegelie.com] Sent: Wednesday, November 28, 2001 7:27 PM To: Daniel Golding Cc: Quibell, Marc; mcohen@thrupoint.net; nanog@merit.edu Subject: Re: MPLS in metro access networks
MPLS is not useful in and of itself as a switching mechanism. However, it is useful for TE, VPNs, etc. If you enable MPLS on your network to get "better performance", "faster speeds", or a "more reliable core", you will be disappointed in the end, as the performance is the same, speed is the same, and reliability is lower due to immature code.
How old is your information?
The company I'm working for has been using MPLS for some 2 years now (maybe more, maybe less, I forget). We have found the code to be quite stable, although that speaks as much to our vendors improved QA as it does to our internal QA and testing that takes place months before deployment.
MPLS-TE is definitely a valuable feature. It was worth it for us to deploy it back in '99, and it's worth it now. MPLS-based VPN's are interesting in their own right.
I would not consider MPLS to be bleeding edge anymore...and for us, it doesn't really feel cutting edge anymore either. It's the newer features still in the standards process that might be dangerous to deploy at this stage, but that's what labs are for (that would be an actual lab, not the "production lab" :-).
That being said, I would love to see some quantifiable data showing the differences in switching latencies between labels and packets. %age increase in efficient use of network capacity will of course depend on your backbone design. Reliability, in the end, has more to do with organization processes for engineering and operating your network than the quality of a vendor's latest GA release of code.
Dave
- Daniel Golding
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Quibell, Marc Sent: Thursday, November 15, 2001 1:04 PM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks
I guess you answered your own question: "And I'm not sure what faster switching/routing has to do with MPLS:)"
As far as CEF and such goes, I couldn't disagree with that (as I was not comparing MPLS to other optimized forwarding techniques), however, MPLS is not a vendor-proprietary forwarding mechanism, which means that I can deploy it worldwide, or state-wide, whatever the case may be, in my network and have the benefit of using only ONE protocol with MPLS-enabled/aware routers/switches. A definate plus over the other proprietary fast switching techniques you mentioned.
Your last statement indicates "added services" have nothing to do with the the fast switching processing of MPLS, when in fact these services depend upon the faster delivery of the non-proprietary fast switching of MPLS. As quoted from the rfc:
"This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services."
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 11:20 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks
I still have to disagree that MPLS results in faster switching/routing in modern service provider networks. Modern vendor caching mechanisms are just as fast if not faster than MPLS processing. With the small overhead of MPLS labels and LDP I highly doubt that you're getting any performance increase over Cisco's CEF or Juniper's FPC architecture. I also doubt that speed is a benefit that service providers consider when deciding whether or not they want to implement MPLS. Added services that run on top of MPLS like VPNs, traffic engineering, and fast rerouting capabilities (all mentioned in the original post) are more likely the benefits considered. Perhaps when label switching was first being marketed (Ipsilon and Cisco in 1996) there were some speed benefits but now I think it's the services that use MPLS that are the major benefit.
-Michael Cohen
-----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:59 AM To: 'mcohen@thrupoint.net'; 'nanog@merit.edu' Subject: RE: MPLS in metro access networks
soooo...Label switching assigns labels to packet headers which results in less time and processing looking up routes, and instead relies upon a label index for forwarding decisions? Hence my statement "faster switching/routing and less processing":)
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:56 AM To: Quibell, Marc Subject: RE: MPLS in metro access networks
I hope so:)
-----Original Message----- From: Quibell, Marc [mailto:mquibell@icn.state.ia.us] Sent: Thursday, November 15, 2001 10:46 AM To: 'mcohen@thrupoint.net'; nanog@merit.edu Subject: RE: MPLS in metro access networks
Are we talking about Multiprotocol Label Switching?
Marc
-----Original Message----- From: Michael Cohen [mailto:mcohen@thrupoint.net] Sent: Thursday, November 15, 2001 10:45 AM To: nanog@merit.edu Subject: RE: MPLS in metro access networks
And I'm not sure what faster switching/routing has to do with MPLS:) I believe one of the ideas behind MPLS benefiting metro access networks is using MPLS to deliver layer 2 VPNs across an MPLS enabled core thus simulating leased lines for access clients...but I'm sure somebody will correct me if I'm wrong. There seems to be some hype for Martini draft VPNs and large enterprise customers in metro areas.
Cheers,
-Michael Cohen
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Quibell, Marc Sent: Thursday, November 15, 2001 10:20 AM To: 'srihari varada'; nanog@merit.edu Subject: RE: MPLS in metro access networks
I would think faster switching/routing and less processing would be wanted in any mid-to-large sized network...I'm not sure what load balancing and fault restoration has to do with MPLS....
Marc
-----Original Message----- From: srihari varada [mailto:varada@txc.com] Sent: Thursday, November 15, 2001 10:12 AM To: nanog@merit.edu Subject: MPLS in metro access networks
Hello:
I have heard some stressing the role of MPLS in metro access networks. It is difficult for me to visualize the need for it in them while it is not so difficult to understand the utility (load balancing and fault restoration etc.) of it in the metro backbone networks.
To characterize metro access networks in the context, the following is provided: -- aggregates traffic from residential (arriving via broadband access links such as xDSL, Cable) and business consumers (arriving via broadband access links such as xDSL and high speed links such as Ethernet or SONET) -- funnels aggregated traffic to metro backbone networks for destination
hosts in the local metro region or remote regions across the internet regional and backbone networks. Majority of such access networks are SONET/ATM based (I didn't come across any case of Gig Ethernet. However, I do not preculde it).
Thus, there are two questions: -- Are there known RBOCs/ILECs and CLECs entrenching MPLS in the said network scope? (I do not see many major ILECs in the un-official MPLS service providers list being circulated but it may mean little) -- If so, what motivates them to do so? Any analysis of the driving forces is appreciated.
Regards,
Srihari Varada
-- Dave Siegel HOME 520-877-2593 dave at siegelie dot com WORK 520-877-2628 dsiegel at gblx dot net Director, IP Engineering, Global Crossing
participants (7)
-
Daniel Golding -
Dave Siegel -
Eric Osborne -
Gary Blankenship -
Leo Bicknell -
Michael Cohen -
Quibell, Marc