Re: MPLS in metro access networks

[Eric Osborne <eosborne () cisco com>]

> 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

Attachment: _bin
Description: