Re: IANA Considerations for RSVP

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

John,
Hmmm... a bit IETF centric.
Because some portion of a problem space touches or uses an IETF protocol,
then clearly the entire problem must belong to IETF.
Consider that the ASON architecture encompasses transport networks where
what we call the transport plane (IETF calls the data plane) is not
necessarily IP. What if the addresses are NSAP addresses instead of IP
addresses? What if some or all of the signaling links employ PNNI
as a signaling protocol instead of RSVP-TE or CR-LDP? Does it still
all belong to IETF? These are problems that cannot be solved without
good cooperation between the standards organizations that are involved.

In terms of the existance of a communication channel and procedures for
collaborating between IETF and ITU-T, this exists but perhaps, in spite
of receiving these liaisons, you have not taken the trouble to become
familiar with it. Identical text describing the collaboration process is
published as RFC 3356 in IETF and as A.Sup3 in ITU-T. We are following
the documented process, and this suggests a different answer than your
emails to the question of which side of this communication channel is
not holding up their end.
Steve

John Drake wrote:
> 
> Stephen,
> 
> I appreciate all the work you've done keep the IETF informed about what the
> ITU is doing.  All I can say is that it doesn't seem to have worked.  Rather
> than continuing to give us status reports on what the ITU is doing, I think
> it would make more sense to do the work in the appropriate IETF working
> groups.
> 
> That was what I thought was the intent of the Feb 19th Liason: "We wish that
> as we continue our review of these protocols you will be able to provide us
> with recommendations on how to close these and future issues."  However, a
> channel of communication has not been established: how should
> recommendations and issues be communicated?  Who makes these, and who
> communicates them?  How does a two-way (or n-way) dialog take place?
> 
> If, on the other hand, these documents were brought into an IETF WG, the
> procedures and channels of communication exist and are well-known.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> Sent: Thursday, January 23, 2003 9:21 AM
> To: David Charlap
> Cc: Brian Hassink; Bob Braden; 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
> 
> 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)
> 
> David Charlap wrote:
> >
> > Brian Hassink wrote:
> > > 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