Subject: RE: IANA Considerations for RSVP

From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
Date: Thu, 23 Jan 2003 11:31:59 -0500

Hi David,

This seems like an unfair characterization. All requests are submitted by individuals. In terms of changing these protocols...

The GMPLS RSVP-TE, which is done in IETF, makes major modifications to RFC3209 and RFC2205 version of RSVP. The rest of the changes been requested are three new objects, new error codes to support these objects. This can hardly be characterized as forcibly changing RSVP or major change in direction...

The extensions that's been requested were derived as a result of discussions and efforts involving many IETF people as well (e.g., please look at the author list of the OIF UNI document). Your comment seems to suggest that the work appear out of nowhere with no participation from the IETF RSVP experts...this is clearly not true...

If you recall, throughout the development of the GMPLS RSVP-TE, the non-RSVP experts (I guess you would lump me in this category as well) provided major comments. As a non-RSVP expert, I tried my best to understand the original goal of RSVP; however, I did not make the initial decision to use RSVP for supporting control plane for transport network. This decision was made collectively by the sub-IP area and thus the GMPLS RSVP was born...

But I think much of this is simply related to the current (lack of) process and procedural issues. These can be dealt with (possibly) at the next meeting, and a clear process should be put in place on how IETF would work with other standards organizations. But this is for the future...

Zhi

-----Original Message-----
From: David Charlap [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 10:56 AM
To: Bob Braden
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked]
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

---

From: David Charlap <[email-masked]>
Date: Thu, 23 Jan 2003 12:01:37 -0500

Lin, Zhi-Wei (Zhi) wrote:
 >
 > The GMPLS RSVP-TE, which is done in IETF, makes major modifications
 > to RFC3209 and RFC2205 version of RSVP. The rest of the changes been
 > requested are three new objects, new error codes to support these
 > objects. This can hardly be characterized as forcibly changing RSVP
 > or major change in direction...

I am not criticizing the existance of GMPLS or the CCAMP work that's 
being done.  All of the IETF people involved in RSVP are aware of this 
and contribute to it as they feel necessary.

I'm far more concerned with non-IETF groups (like ITU, ATM Forum and 
others) deciding to develop their own incompatible extensions without 
even informing any IETF groups of their actions.

Groups like these should not be extending IETF protocols without 
consulting with the relevant IETF working groups.  Otherwise we end up 
with extensions that duplicate existing IETF functionality, don't 
coexist gracefully, and/or break interoperability.  And if these 
extensions become popular in products, the IETF will be forced to 
include them in the standards in order to prevent future IETF work from 
breaking them.

 > The extensions that's been requested were derived as a result of
 > discussions and efforts involving many IETF people as well (e.g.,
 > please look at the author list of the OIF UNI document). Your comment
 > seems to suggest that the work appear out of nowhere with no
 > participation from the IETF RSVP experts...this is clearly not
 > true...

I am not referring to OIF UNI.  They are doing consulting with relevant 
IETF groups as a part of their work.

I must have struck a nerve here, because yours is the second response 
I've gotten from somebody who thinks I'm referring to their specific 
IETF-approved RSVP extension, even though I specifically said I'm 
referring to extensions developed without IETF involvement.  And I think 
that was Bob's original issue as well - since he explicitly mentioned 
IANA RSVP requests coming from non-IETF sources.

-- David

---

From: Eric Gray <[email-masked]>
Date: Thu, 23 Jan 2003 12:42:34 -0500

Zhi,

    Yours may be an equally unfair characterization.  In general, the reaction
in the IETF to any intended RFC submitted as a 'fait accompli' is similar to
what you are seeing here - regardless of whether it came from an individual
or an organization representative.

> This seems like an unfair characterization. All requests are submitted by individuals. In terms of changing these protocols...

...

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 23 Jan 2003 10:52:30 -0800 (PST)

Hi Zhi,

On Thu, 23 Jan 2003, Lin, Zhi-Wei (Zhi) wrote:

> Hi David,
>
> This seems like an unfair characterization. All requests are submitted
> by individuals. In terms of changing these protocols...

I beg to differ.  The publication request of the original RSVP-TE spec was
made *by the MPLS WG*.  The publication request of the GMPLS RSVP spec was
makde *by the CCAMP WG*.  Furthermore, the issue is not who submits the
document; it is the degree of scrutiny it gets.  *Standards Track* docs
go through a much stricter review than informational ones.

> The GMPLS RSVP-TE, which is done in IETF, makes major modifications to
> RFC3209 and RFC2205 version of RSVP. The rest of the changes been
> objects. This can hardly be characterized as forcibly changing RSVP or
> major change in direction...

Do you consider deprecating ResvErr and ResvTear not "forcibly changing
RSVP or major change in direction"?

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 23 Jan 2003 10:59:04 -0800 (PST)

> referring to extensions developed without IETF involvement.

If you are under the impression that
draft-lin-ccamp-gmpls-ason-rsvpte-04.txt is "IETF approved", I don't
blame you.  But in fact, it is not (yet).  And even if it does get
approval, it is as an *Informational* document.

But you have struck a nerve with some (and a chord with me :-))

Kireeti.

---

From: Yangguang Xu <[email-masked]>
Date: Thu, 23 Jan 2003 14:20:22 -0500

Kireeti,

> RSVP or major change in direction"?

Well, it's my turn to beg to differ :) If you read the document && understand it
&& don't take any prejudice, then it may be more like specifying rules for using
a protocol for an application with some hard requirements.

Regards,

Yangguang