The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] QoSRe: Here we go again (Re: RSVP Hello)
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
|
|