The MPLS WG Archive
[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index]
Here we go again (Re: RSVP Hello)
-
From: "David Allan" <dallan@nortelnetworks.com>
-
Date: Mon, 27 Aug 2001 09:59:51 -0400
-
Cc: bill.sanford@netplane.com, cmartin@gnilink.net, mpls@UU.NET
-
X-Orig: <dallan@americasm01.nt.com>
Title: RE: Here we go again (Re: RSVP Hello)
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:pingpan@juniper.net]
Sent: Sunday, August 26, 2001 2:01 AM
To: neil.2.harrison@bt.com
Cc: bill.sanford@netplane.com; cmartin@gnilink.net; mpls@UU.NET
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
|