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