MPLS in metro access networks

Thu Nov 29 20:02:36 UTC 2001

-----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 at siegelie.com]
> Sent: Wednesday, November 28, 2001 7:27 PM
> To: Daniel Golding
> Cc: Quibell, Marc; mcohen at thrupoint.net; nanog at 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 at merit.edu [mailto:owner-nanog at merit.edu]On
> > Behalf Of Quibell, Marc
> > Sent: Thursday, November 15, 2001 1:04 PM
> > To: 'mcohen at thrupoint.net'; nanog at 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 at thrupoint.net]
> > Sent: Thursday, November 15, 2001 11:20 AM
> > To: nanog at 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 at icn.state.ia.us]
> > Sent: Thursday, November 15, 2001 10:59 AM
> > To: 'mcohen at thrupoint.net'; 'nanog at 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 at 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 at icn.state.ia.us]
> > Sent: Thursday, November 15, 2001 10:46 AM
> > To: 'mcohen at thrupoint.net'; nanog at merit.edu
> > Subject: RE: MPLS in metro access networks
> > 
> > 
> > Are we talking about Multiprotocol Label Switching?
> > 
> > Marc
> > 
> > 
> > -----Original Message-----
> > From: Michael Cohen [mailto:mcohen at thrupoint.net]
> > Sent: Thursday, November 15, 2001 10:45 AM
> > To: nanog at 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 at merit.edu [mailto:owner-nanog at merit.edu]On
> > Behalf Of Quibell, Marc
> > Sent: Thursday, November 15, 2001 10:20 AM
> > To: 'srihari varada'; nanog at 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 at txc.com]
> > Sent: Thursday, November 15, 2001 10:12 AM
> > To: nanog at 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-----