RE: IANA Considerations for RSVP

["Brian Hassink" <BHassink@HatterasNetworks.com>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

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:David.Charlap@marconi.com]
Sent: Thursday, January 23, 2003 10:56 AM
To: Bob Braden
Cc: 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


Bob Braden wrote:
> 
> 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 
protocol for their features, often without first bothering to check if 
there are already obects defined by IETF standards that already serve 
their purposes.  And even in those cases where new objects may be 
required, the proposed objects are often defined as having semantics 
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 
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 
RSVP just because it's popular in MPLS and then try to change it into 
what they really want.  This is especially true in those situations 
where their proposed changes would produce a fundamentally incompatible 
protocol.

Unfortunately, I don't know what can be done about this.  These groups 
seem hell-bent on hacking up RSVP without first learning it's design 
philosophy.  If they don't get assignments from IANA, they'll probably 
just make their own assignments without any coordinating facility, and 
we'll wind up with several mutually incompatible protocols that all want 
to call themselves "RSVP".

-- David