I'm sorry, I still don't understand your points. I guess will just have to
agree that we disagree. Whether were talking about Riverstone, Juniper,
Cisco, or any other vendor for that matter, they all have their own
proprietary caching and forwarding mechanisms which allow them to forward at
(or near:) the speeds their marketing people brag about. I have never seen
nor heard (even from marketing personnel) that MPLS increases the speeds and
throughput of any vendor's box. It adds services yes, but not speed. If
you've seen anything proving these statements wrong please point me in the
right direction as I'm always anxious to learn more however, I've
implemented a few MPLS networks (in Europe and the US) in my time and have
yet to see or hear of any speed benefits...
-Michael Cohen
-----Original Message-----
From: Quibell, Marc [mailto:mquibell@icn.state.ia.us]
Sent: Thursday, November 15, 2001 2:33 PM
To: 'mcohen(a)thrupoint.net'
Subject: RE: MPLS in metro access networks
And I say that "local cache implementations" are even more cumbersome
(Proprietary) on mid-to-large sized networks, which is where one would
implement MPLS, especially when you have a lot of different (vendor) routers
and switches. Cisco may require CEF first (doesn't make sense to do so,
using one over the other) but Riverstone and others do not. And implementing
a proprietary forwarding method under MPLS is just a bother, but if
required, will be accomplished to implement a Network-wide label switching
methodology. I can now have network end-to-end MPLS (fast switching, less
processing), instead of a cornicopia of mixed express forwarding, which do
not propogate between routers, and which then requires each router to
process the fast switching instead of just reading a label and forwarding
it...And so, the other point is that it has to be implemented anyways in
order to run VPN over MPLS.
Cheers to you as well...
Marc
-----Original Message-----
From: Michael Cohen [mailto:mcohen@thrupoint.net]
Sent: Thursday, November 15, 2001 12:45 PM
To: nanog(a)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 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(a)thrupoint.net'; nanog(a)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(a)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(a)thrupoint.net'; 'nanog(a)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(a)thrupoint.net'; nanog(a)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(a)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(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of
Quibell, Marc
Sent: Thursday, November 15, 2001 10:20 AM
To: 'srihari varada'; nanog(a)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(a)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
