|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical 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: [email protected] [mailto:[email protected]]On Behalf Of > Quibell, Marc > Sent: Thursday, November 15, 2001 1:04 PM > To: '[email protected]'; [email protected] > 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:[email protected]] > Sent: Thursday, November 15, 2001 11:20 AM > To: [email protected] > 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:[email protected]] > Sent: Thursday, November 15, 2001 10:59 AM > To: '[email protected]'; '[email protected]' > 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:[email protected]] > 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:[email protected]] > Sent: Thursday, November 15, 2001 10:46 AM > To: '[email protected]'; [email protected] > Subject: RE: MPLS in metro access networks > > > Are we talking about Multiprotocol Label Switching? > > Marc > > > -----Original Message----- > From: Michael Cohen [mailto:[email protected]] > Sent: Thursday, November 15, 2001 10:45 AM > To: [email protected] > 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: [email protected] [mailto:[email protected]]On Behalf Of > Quibell, Marc > Sent: Thursday, November 15, 2001 10:20 AM > To: 'srihari varada'; [email protected] > 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:[email protected]] > Sent: Thursday, November 15, 2001 10:12 AM > To: [email protected] > 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
|