RE: IANA Considerations for RSVP

[John Drake <jdrake@calient.net>]

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