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

From: "David Allan" <[email-masked]>
Date: Mon, 27 Aug 2001 10:31:18 -0400

Loa:

PPP and L2TP are examples of IETF defined protocols that carry IP (and other
things), would not be considered specifically part of IP, and are generally
self contained from a functional POV. I'd lump MPLS in the same category.

rgds
Dave

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Monday, August 27, 2001 10:19 AM
To: [email-masked]
Cc: Allan, David [CAR:NS00:EXCH]
Subject: Re: Here we go again (Re: RSVP Hello)

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

-- 
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: Eric Gray <[email-masked]>
Date: Mon, 27 Aug 2001 11:40:33 -0400

This seems like a noisy thread.  Some people (Neil and Dave) assert that
OAM must be part of a long term solution and - hence - anything that does
not contribute materially to this long term solution is going to be wasted
effort.  Others (Loa and Ping) assert that the immediate solution should
be simple and useful - or it will be irrelevant.

We're getting dangerously close to name calling from both sides - perhaps
we may already have crossed the line.  Probably the thing to do at this
point is to agree to disagree.  I suggest that people who are interested
and believe in the value of a long term solution work on that solution
while other people who are interested in and believe in a simple, useful,
immediate solution work on that solution.  Ultimately, each group may end
up borrowing from the other - possibly bettering both solutions - and, at
some point, it is likely that one solution or the other will be overcome
by events.

In the meantime, can we stop arguing which is better, a bolt or a cotter
pin?

Thanks in advance,
--
Eric Gray

> things),
> would not be considered specifically part of IP, and are generally self
> contained from
> a functional POV. I'd lump MPLS in the same category.
>
> rgds
> Dave
>

---

From: Loa Andersson <[email-masked]>
Date: Mon, 27 Aug 2001 19:21:02 +0200

Eric,

it is always refreshing to have someone telling what I said. The way 
you summarize it fair - s long as the "long term" don't stop the work
on the "immediate and simple".

What I thought I said was that already the immediate is to complex and
has too many not needed bells and whistles.

I'll stop this thread here, but will go on arguing for further
simplicity
and usefulness where ever.

/Loa