Subject: RE: IANA Considerations for RSVP

From: "Brian Hassink" <[email-masked]>
Date: Thu, 23 Jan 2003 11:06:53 -0500

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-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 11:15:21 -0500

> 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

---

From: Scott W Brim <[email-masked]>
Date: Thu, 23 Jan 2003 12:09:35 -0500

> protocol to an MPLS protocol?

Check the documentation.  RSVP is not an intserv protocol.  It's
(potentially) used by intserv.  It's also used for other things.

---

From: Stephen Trowbridge <[email-masked]>
Date: Thu, 23 Jan 2003 10:21:15 -0700

David,
To read these emails, it sounds as though you think that the people who
are doing this are brand new to the technology and never even considered
working with IETF to try to solve the problem. Perhaps you haven't followed
the ccamp work so closely, but here is some history:
- On October 21, 2001, ITU-T Study Group 15 sent IETF ccamp a liaison statement
  regarding our new documents with requirements and architecture for
  switched (not necessarily IP) transport networks. This included a protocol-
  neutral model for call and connection management (signaling). In copies
  of the ITU-T documents were made available to non-ITU-T members via an
  ftp site. The liaison was placed on the IESG web site and was presented
  in the ccamp meeting in Salt Lake City in December. At that same meeting,
  Maarten Vissers gave a technical presentation in the sub-IP area meeting
  regarding the ITU-T work in this area.
- On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding
  the gaps that had been identified between the ITU-T requirements (sent
  earlier) and what seemed to be implemented by the GMPLS protocols. Specifically,
  1. Call & Connection separation, e.g., a call provides the service
     relationship, which may support connection operations as part of a call. 
  2. Additional error codes/values, for example, for connection rejection
     (invalid connection ID). 
  3. Restart mechanisms: Depending on the introduction by the ITU of additional
     control plane resiliency requirements, enhancements of the protocol
     (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be required. 
  4. Protocol enhancements in CR-LDP for support of crankback capability from
     intermediate nodes. 
  This liaison was presented in the Minneapolis IETF meeting during the ccamp
  working group and posted on the IESG web site. The liaison requested
  assistance in closing these gaps and invited input from IETF on our work
  in ITU-T.
- At the April/May 2002 meeting of ITU-T Study Group 15 meeting, contributions
  were considered to close these gaps, resulting in text for draft Recommendations
  G.7713.2 (our rsvp-te document) and G.7713.3 (our cr-ldp document). Again,
  we sent a liaison (dated May 10, 2002) to ask for comments on our draft
  Recommendations (made available on the ftp site), to request alignment, and
  to ask for IANA code point assignments. To quote from that liaison:
"Please consider including the proposed solutions provided in G.7713.2 and G.7713.3
to update the existing GMPLS signaling work in support of ASON requirements.
We hope that you can help expedite the assignment of appropriate additional
error codes/values by IANA.  These are needed for both RSVP-TE and CR-LDP."
  This liaison was presented at the Yokohama IETF ccamp meeting.

  To refer to one point raised earlier in the thread, there are other cases
  where IANA has assigned codepoints for work outside of IETF, including
  other CCITT/ITU-T work, IEEE, IEC, etc. This request had been made last
  May, with no response.
- Some final work was done on our drafts at a Rapporteur meeting in October,
  with one result being another liaison (dated October 11, 2002) making
  another plea for comments and help getting the codepoints assigned. This
  liaison was presented at the Atlanta IETF ccamp meeting, and still no
  response or IANA action.

To hear now that someone thinks that the ASON work in ITU-T is some kind
of secret end-run around IETF, and not involved with or related to the
work being done internally in IETF is absurd. At every stage of the work,
IETF was kept informed of the work and invited to participate. At the
invitation for help to address the additional ITU-T requirements, there
was no response. As ITU-T progressed this work and invited further comments
and alignment of the base GMPLS protocols, again no response. And to the
final pleas for comments and codepoint assignments, no response.

I contrast this with our interaction with the ATM forum on the same topic.
Certain operators in ITU-T are interested in using the PNNI protocol for
this application (rather than rsvp-te or cr-ldp). The ATM forum has
responded with a formal liaison into the current ITU-T Study Group 15
meeting where they have given us a diffmarked copy with extremely
helpful and constructive suggestions about how to align our G.7713.1
document with their work.

After some private communication with the Area directors, we received some
advice that one tool that might be used to finally get the IANA codepoint
assignment complete would be to publish what we were doing in ITU-T as
informational RFCs. This is the stage we are at today, and given the
history I describe above, I do not think anybody can say that we are
at this point because any of us did not do everything possible to
do this work (a) in IETF, with the initial communication of requirements;
or (b) in cooperation between ITU-T and IETF, once this work had
progressed in ITU-T.

But this is all water under the bridge. We are at the point of trying
to get some codepoints assigned for ITU-T documents we are trying to
complete. Nobody should say "no" at this point because they think we
didn't try to work this IN or WITH IETF first. It should be clear to
all that this is not the case.
Regards,
Steve Trowbridge
(vice-chairman, ITU-T Study Group 15)

---

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

Hi David,

> understing it, and without even notifying the IETF groups that did all

Just notifying is insufficient.  A detailed review, the ability to make
comments and changes, going through the IETF process (such as it is)
is MANDATORY for protocol changes.  Moreover, making the spec standards
track means that new specs can cite it *normatively*.

<clipped>

> Not only isn't this happening, but there appears to be no desire to see

Well, it's like pulling teeth.  But we're on the first step -- you can
thank Bob for that!

Kireeti.