The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] IANA Considerations for RSVP
Hello, First, the IETF has been instrumental in putting IP/MPLS protoocols for use in the optical control plane. You can't now complain that RSVP is being indiscriminately used for purposes other than intended. To quote a cliche, you can't have the cake intact and modify it too. Second, none of the IETF WGs (specifically, CCAMP) have shown any interest in discussing the (informational) drafts about ASON or OIF at any length. Serious consideration by the WGs should lead to an examination of the solutions proposed and a liaison to ITU-T or OIF or whichever body about tweaks that are out of whack with the protocol architecture. Instead, what we usually end up with are WG Rambos who simply shoot down the entire model of ITU-T or OIF and move on. Finally, it's not so easy to steer away from RSVP altogether (even if it makes sense to do so) due to the installed code base of dominant vendors. In summary, there is a lot of pressure to use RSVP outside of IETF, and the IETF should systematically review the outside work to ensure technical sanity. Regards, Bala Rajagopalan Tellium, Inc. 2 Crescent Pl. Ocean Port, NJ 07757 USA Ph: +1-732-923-4237 Email: braja@tellium.com > -----Original Message----- > From: David Charlap [mailto:David.Charlap@marconi.com] > Sent: Thursday, January 23, 2003 11:15 AM > To: Brian Hassink > Cc: Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org; mpls@UU.NET; > kireeti@juniper.net; iana@ISI.EDU; sob@harvard.edu; mankin@psg.com; > bwijnen@lucent.com > Subject: Re: IANA Considerations for RSVP > > > Brian Hassink wrote: > > Didn't the IETF set the precedent by extending RSVP from an > IntServ protocol to an MPLS protocol? > > There's a big difference. MPLS and IntServ are both IETF > groups. (And > RSVP has/had its own working group anyway). Also, most of > the key RSVP > people were involved in the development of RSVP-TE. > > This is very different from what I'm describing - where > people who have > no prior RSVP experience decide that they can start changing > it without > understing it, and without even notifying the IETF groups > that did all > of the development work. > > I'mnot saying that RSVP should never be extended. I'm saying > that those > groups that are writing extensions should be consulting with > those who > have been developing and maintaining it (in the RSVP and MPLS > groups) in > order to ensure that: > - Their goal can't be achieved without extending the language > - That their extension doesn't overlap a similar extension > from somebody else. > - That their extension doesn't significantly change the overall > semantics of RSVP. > - That their extension is sufficiently flexible so that other > groups can build off of it instead of re-inventing the wheel > with yet another incompatible extension. > > Not only isn't this happening, but there appears to be no > desire to see > this happen. > > -- David >
|
|