North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: MPLS in metro access networks
> 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:[email protected]] > > Sent: Wednesday, November 28, 2001 7:27 PM > > To: Daniel Golding > > Cc: Quibell, Marc; [email protected]; [email protected] > > 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: [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 > Attachment:
pgp00008.pgp
|