Subject: RE: Here we go again (Re: RSVP Hello)

From: "David Allan" <[email-masked]>
Date: Mon, 27 Aug 2001 09:59:51 -0400

Ping:

I think the disconncect as to what MPLS "is" needs to be resolved. I think
there is a large community that would be hard pressed to describe it as part
of IP, at least as large as the commnunity trying to avoid having it called
an ATM replacement (IMHO if we're looking for a monnicker; Frame relay in
IP's image is really probably closer ;-). 

From a functional point of view it does insert stuff into the stack, call it
a layer, helper or whatever, but to suggest it is not there, or is really an
appendage, or can be dealt with piecemeal means we're going to be fixing
this thing for a long time. This is where "architecture" is not religion but
a genuinely useful discipline.

I'm sure your proposal works for what it was designed to do, but IMHO it is
a subset of what is required, and would most likely be rendered to be
superfluous baggage by any LTSFGTC. Which means MPLS will not be simple.

rgds
Dave 

-----Original Message-----
From: Ping Pan [mailto:[email-masked]]
Sent: Sunday, August 26, 2001 2:01 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Here we go again (Re: RSVP Hello)

<snip>

Sigh,,, after reading through this mail, I can relate to the feeling 
some people have on MPLS, that is, it's an ATM replacement. :-( I really 
hope not.

Normally, the buzzwords such as "layers", "principles" and 
"architectures" are defined to make it easier to describe things. They 
are not defined to create new religions. Sometimes, they are more useful 
to marketing than to engineering. So if something is useful to the 
Internet, we try to come up with a simple solution and just build it. 
There is no magic to this process. So instead of talking about how I 
have broken the layers, principles, architectures and religious rules in 
LSP-ping, tell me why it does not work for the purpose it was designed for.

> During the discussion of the Ping draft, I know Yakov described what I
have
> discussed above as 'working on LTSFGTC' (long-term solutions for
generations
> to come)...or something like that......but if we want MPLS itself to be a
> LTSFGTC (and hopefully also give some solid foundation for those working
in
> the PWE3 and PPVPNs WGs) then we really have to get some of the basic OAM
> architectural tenets right at the outset. 

If OAM is a great LTSFGTC, then there is nothing to be worried about on 
this "narrow-focused" LSP-ping. We do our work, and you do yours. What a 
beautiful thing!

> Proper data-plane OAM, and its
> decoupling from other client/server layer data-planes and/or specific
> control (or management) plane protocols is not a 'luxury item', its just
> plain common sense to avoid problems down the road.
> 

It's also a common sense that in order to make MPLS working in the 
Internet, we need to keep it simple.

Regards,

- Ping

---

From: Loa Andersson <[email-masked]>
Date: Mon, 27 Aug 2001 16:18:42 +0200

All,

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!

The second requirement is usefulness, if MPLS is not useful, there will
be no MPLS (even though it is simple).

Start looking at what is there and see if these requirements are met 
otherwise take it out.

BTW

What do our AD's/WG's chairs think about the statement that this is not 
part of the IP protocol suite, if you agree why are we doing this in 
IETF?

/Loa

> David Allan wrote:
> 
> Ping:
> 
> I think the disconncect as to what MPLS "is" needs to be resolved. I
> think there is a large community that would be hard pressed to
> describe it as part of IP, at least as large as the commnunity trying
> to avoid having it called an ATM replacement (IMHO if we're looking
> for a monnicker; Frame relay in IP's image is really probably closer
> ;-).
> 
> From a functional point of view it does insert stuff into the stack,
> call it a layer, helper or whatever, but to suggest it is not there,
> or is really an appendage, or can be dealt with piecemeal means we're
> going to be fixing this thing for a long time. This is where
> "architecture" is not religion but a genuinely useful discipline.
> 
> I'm sure your proposal works for what it was designed to do, but IMHO
> it is a subset of what is required, and would most likely be rendered
> to be superfluous baggage by any LTSFGTC. Which means MPLS will not be
> simple.
> 
> rgds
> Dave
> 
> > During the discussion of the Ping draft, I know Yakov described what
> I have
> > LTSFGTC (and hopefully also give some solid foundation for those
> working in

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se

---

From: Sham Chakravorty <[email-masked]>
Date: Mon, 27 Aug 2001 03:30:33 -0700

See comments inline -

> 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.
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.)

> 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.

SC

---

From: Eric Osborne <[email-masked]>
Date: Mon, 27 Aug 2001 23:11:13 -0400

> See comments inline -

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

> 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.  

> the broad day light to put out an article with such a title just a year

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...:)

> 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

---

From: Ping Pan <[email-masked]>
Date: Mon, 27 Aug 2001 21:06:18 -0700

> withstanding mixed VC setup criteria of RSVP-TE and CR-LDP for a starter.

Would you please elaborate the relationship between simplicity and the 
number of drafts? Do you imply that the number of draft is more 
important than what's actually been implemented?

> Majority taking the poll seem have to said, yes. 

Sure. Let's have more chat room talks. I am sure this must be some 
in-depth technical conversation.

---

From: Loa Andersson <[email-masked]>
Date: Tue, 28 Aug 2001 11:23:07 +0200

All,

promissed not to add to the noise un-necessarily, but since this is
one of those wonderfully unstructured threads where you can say 
anything and get flogged whether it is sensible or not.

I can't resist:

There seems to be at least four different views voiced on this 
thread.

1. "MPLS is níce and dandy, nothing needs to be done, just because it
   is not an ATN replcement"
2. "MPLS is níce and dandy, nothing needs to be done, just because it
   is not an ATN replcement"
3. MPLS is not nice and dandy, because it is ATM all over again.
4. MPLS is nice and dny, but there is a need to review what we ccome up
   with so far, we don't want to make the same misstakes all over again.

Understanding that there are an enormous potential make this far more 
granular, but won't just now.

I think that while recognizing that MPLS is useful and simple at the
core,
there is still a need to go back and asked ourselves if everything that 
has been added is needed.

/Loa