Er...CEF-Cisco Express Forwarding-is proprietary to Cisco only. It is
proprietary because you do not run Cisco Express Forwarding on a Juniper, or
a ....ahh forget it. Yes we know what is cache and what is not..Try not to
take things so liberal here and start nitpicking. People usually know what a
flow is here and the fact that your definition may or may not not indicate
that CEF is actually building a flow is not really relevent, since I was not
trying to say it did. I just used the term for time's sake. If i were to
really describe CEF in a white paper, I may or may not use the term flow.But
the point is that it is not in the scope of this discussion. Chill out with
the criticisms.....
Marc
-----Original Message-----
From: Eric Osborne [mailto:eosborne@cisco.com]
Sent: Thursday, November 15, 2001 5:34 PM
To: Quibell, Marc
Cc: 'mcohen(a)thrupoint.net'; nanog(a)merit.edu
Subject: Re: MPLS in metro access networks
On Thu, Nov 15, 2001 at 03:21:31PM -0600, Quibell, Marc wrote:
>
> My only contentment was the fact that w/o cef or other proprietary
> mechanisms or even with them, mpls, provided it is supported on all
> enterprise routers and switches (cef and others are layer 3), mpls is both
> layer 2 and 3.
I think there's some confusion here. Where does it say that CEF is
proprietary? CEF is just a way to do a lookup on a destination IP
address. At its heart it's an mtrie; ask any computer science
undergrad to tell you how long mtries have been around. other vendors
have similar schemes.
cef is also not a cache. cache implies things that enter and leave as
they are used (a la fast switching or ram<->disk swapping algorithms);
cef does not do that. cef only inserts/removes prefixes from the fib
based on a routing table (rib) change.
it also happens to be true that the lookup component of cef (mtrie for
IP packet destination addresses) have nothing to do with the lookup
for a labeled packet. the reason cef has to be enabled is that the
act of enabling cef sets all sorts of things like switching vectors
and other useful gunk on an interface that are a prerequisite for mpls
forwarding. cisco is trying very very hard to move away from caching
schemes for ip forwarding; they don't scale. if we had our druthers
(no snide comments from the peanut gallery, please!) there would be
nothing be cef out there right now. the other IP-DA lookup mechanisms
no longer make sense. note that they *did* make sense when network
hardware space (memory) was at a premium and routing tables were
smaller/less variable than they are today.
> MPLS can be implemented on switches not capable of analyzing network
> layer packets (thus no cef).
again, confusion. mpls can be implemented on vendor's boxes other
than cisco, thus no cef there as well.
> In the overall network scheme with complete MPLS configuration, this
> is where I can see the speed increase. You speak of cef and the fpc,
> yet each router hop would have to process it's own forwarding flow
> setup, and then of course use it's own express "routing table".
it's debatable whether the word "flow" makes sense here, either.
certainly traffic flows from one point to another, but don't get
labels confused with flows in the Netflow sense; something that comes
and goes based not on routing table, but on actual traffic.
> Even in this instance MPLS, having only to setup the flow once by
> labeling it at the first hop, need not go through other express
forwarding,
> proprietary, algorithms. This instance in itself would increase lan/wan
> speed, at least IMO.
Nope. It turns out that a 32-bit DA lookup and a 20-bit label lookup
are pretty much the same speed. It of course depends on your
implementation, but in general the label lookup and the DA lookup are
the same speed, or very close. It was originally thought that mpls
would increase forwarding speed, but that was several years ago, when
we didn't have the hardware abiities we do today. The thing mpls buys
you is that you seperate the properties of your traffic from the
routing of your traffic, so you can carry VPN (overlapping ip
addresses) and non-IP traffic across an IP backbone scalably. This
also gets you TE, where you forward traffic without regard to IP
destination address, which lets you use paths in your network other
than the one(s) your IGP chooses.
> You may call this negligable, but that of course depends upon the
> overall volume of traffic and processing. I also must note that
> traffic engineering should be included with the MPLS setup.
traffic engineering is not done on demand the way you seem to imply.
TE LSPs are set up according to a traffic matrix or other such
administrative concern, and typically have a lifetime of hours to
days. and of course, MPLS != MPLS-TE; LDP's setup works differently,
although I must reiterate that RSVP does not cause delays for packets
going through the network.
Having said that, the only case when the fact that you use MPLS-TE can
cause delays is when a TE LSP goes down and you have to drop packets
until you can fall back to IP routing or build another LSP. But
MPLS-TE has protection mechanisms that minimize this packet loss, and
do a much, much better job at reducing loss than IP can.
eric
>
> Marc
>
>
>
>
> -----Original Message-----
> From: Michael Cohen [mailto:mcohen@thrupoint.net]
> Sent: Thursday, November 15, 2001 2:54 PM
> To: nanog(a)merit.edu
> Subject: RE: MPLS in metro access networks
>
>
>
> 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
