The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Aug> msg00356



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

QoSRe: Here we go again (Re: RSVP Hello)

  • From: Eric Osborne <eosborne@cisco.com>
  • Date: Mon, 27 Aug 2001 23:11:13 -0400
  • Cc: Loa Andersson <loa.andersson@utfors.se>, mpls@UU.NET
  • User-Agent: Mutt/1.3.13i
  • X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562

On Mon, Aug 27, 2001 at 03:30:33AM -0700, Sham Chakravorty wrote:
> See comments inline -
> 

I'm probably just fanning the flames of a religious war, but what the
hell...


> > I'll try to be even more to the point - the first and foremost requirement
> > is simplicity. If MPLS is not simple, there will be no MPLS!
> 
> In IMHO, MPLS is not simple.  Consider all the drafts that have been
> fielded for the past four years - over 120 (?) or so to solve its
> many issues - not withstanding mixed VC setup criteria of RSVP-TE
> and CR-LDP for a starter.

Sure, but consider also the number of large MPLS deployments.  One
would never add an additional control plane or two to a network if
there were no benefit to be gained from it; it seems obvious that at
least some people have decided the potential benefits of MPLS are
worth whatever hassle it brings.  

> MPLS unfortunately does not meet the simplicity criterion. (You may have
> prophesized something here in line with what is coming out in the press more
> and more.  See Lightreading.com's recent article: "Poll: Is MPLS BS?"
> Majority taking the poll seem have to said, yes. One would have been hung in
> the broad day light to put out an article with such a title just a year
> ago.)

Can you enumerate these 'simplicity criterion'?  And as you do so, try
to come up with rules that demonstrate that MPLS is not simple but
BGP, OSPF, IS-IS, IP, ATM, and/or SONET are.

And not that I want to start trashing prestigious on-line industry
trade rags, but lightreading strikes me as the Daily Star of the
Internet news industry.  But I suppose I'm biased; I work for Big
Brother...:)

> 
> > The second requirement is usefulness, if MPLS is not useful, there will be
> > no MPLS (even though it is simple).
> 
> With no built-in framework for QoS deployment and no extensibility to
> enterprise networks (over Ethernets, e.g.), its usefulness as many have
> pointed out before, on this board and elsewhere, is at best very limited.

I guess I don't understand the point about QoS.  Pretty much every
vendor I've ever dealt with treats the EXP bits as Precedence bits.
So there's no inherent *additional* QoS framework in MPLS, but it can
certainly be deployed in much the same way as IP QoS can.  And I
suspect that if MPLS had a built-in QoS framework, then the pundits
would use this to claim that MPLS was not simple.  However, ongoing
work (DS-TE and L-LSP) will give more granular control over QoS than
IP has, albeit at a price of complication.

As far as extensibility to enterprise networks, are you talking about
the various forms of L2 over MPLS?  It seems to me that these things
very much exist; we are shipping two different transport types, and at 
least 3 other vendors that I know of have some flavor of L2 over
MPLS.  And depending on how you define extensability, there's always
2547 and its ability to merge with the enterprise IGP at a L3 level.

'simple' != 'effortless'.  Nothing in networking is effortless.  A
better way to look at it, IMHO, is whether the tradeoff in deploying
MPLS to do whatever services you want (L2 transport, L3 VPNs, TE,
BGP-free core, whatever) is worth the work of an extra few control
planes, a new set of operational things to learn, and so forth.  if
it's worth it, use MPLS; if it's not, don't.



eric