RE: IANA Considerations for RSVP
"Brian Hassink" <[email protected]> Thu, 23 Jan 2003 11:06:53 -0500
| Newsgroups | gmane.ietf.mpls,gmane.ietf.rsvp,gmane.ietf.ccamp |
|---|---|
| Message-ID | <[email protected]> |
Didn't the IETF set the precedent by extending RSVP from an IntServ = protocol to an MPLS protocol? CR-LDP exists as a purpose built alternative, but vendor politics = resulted in the above precedent. Just my opinion. Cheers, Brian -----Original Message----- From: David Charlap [mailto:[email protected]] Sent: Thursday, January 23, 2003 10:56 AM To: Bob Braden Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: IANA Considerations for RSVP Bob Braden wrote: >=20 > There is a growing unease about IANA assignments of RSVP parameters -- > object numbers, CTypes, message types, and error numbers -- for new > uses of RSVP. Many of these IANA requests, but not all, originate > outside the IETF in other standards bodies. Many of the people from > outside the IETF were not part of the RSVP working group and so did = not > absorb the technical rationale behind RSVP; in fact, they are = sometimes > barely clued into IETF procedures at all. I've noticed the same thing. It seems that many non-IETF groups want to = use RSVP, and all believe that they must create extensions to the=20 protocol for their features, often without first bothering to check if=20 there are already obects defined by IETF standards that already serve=20 their purposes. And even in those cases where new objects may be=20 required, the proposed objects are often defined as having semantics=20 that differ greatly from the way RSVP usually operates. In other words, these groups seem to want to forcibly change RSVP into a = protocol that more closely resembles some other protocol that they're=20 more intimately familiar with. Personally, I don't like this. These groups should step back and decide = if RSVP is really what they need. If they require a different protocol, = then they should use a different protocol - they should not glom onto=20 RSVP just because it's popular in MPLS and then try to change it into=20 what they really want. This is especially true in those situations=20 where their proposed changes would produce a fundamentally incompatible=20 protocol. Unfortunately, I don't know what can be done about this. These groups=20 seem hell-bent on hacking up RSVP without first learning it's design=20 philosophy. If they don't get assignments from IANA, they'll probably=20 just make their own assignments without any coordinating facility, and=20 we'll wind up with several mutually incompatible protocols that all want = to call themselves "RSVP". -- David