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)
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 > > > 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:loa.andersson@utfors.se] > Sent: Monday, August 27, 2001 10:19 AM > To: mpls@UU.NET > 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: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 > > -- > 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 loa.andersson@utfors.se > WWW www.utfors.se
|
|