Subject: RE: IANA Considerations for RSVP

From: John Drake <[email-masked]>
Date: Thu, 23 Jan 2003 11:31:30 -0800

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:[email-masked]]
Sent: Thursday, January 23, 2003 9:21 AM
To: David Charlap
Cc: Brian Hassink; Bob Braden; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
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

---

From: Stephen Trowbridge <[email-masked]>
Date: Thu, 23 Jan 2003 16:24:31 -0700

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

---

From: Scott W Brim <[email-masked]>
Date: Thu, 23 Jan 2003 19:26:55 -0500

> then clearly the entire problem must belong to IETF.

The entire problem of signing off on extensions to the protocol does
belong to the IETF, if you want them to be used outside of some local
network.  That's for architectural consistency.

> good cooperation between the standards organizations that are involved.

The IETF is responsible for defining the mechanisms by which those
non-IP addresses can be carried in the IP-based protocol.

> not holding up their end.

I agree the communication channels could be used better.  I also think
that the best way to communicate is probably NOT those channels, but
rather to bring in parallel technical contributions in each group, to
make sure they are in sync.  Take the ideas through the procedures that
participants actually care about.

swb

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 27 Jan 2003 17:40:58 -0500

> not holding up their end.

Please take careful note of the last sentence.

  3.2.2 ITU-T Recognition at ISOC/IETF

   ITU-T Study Group Chairmen can authorize one or more members to
   attend an IETF meeting as an official ITU-T delegate speaking
   authoritatively on behalf of the activities of the Study Group (or a
   particular Rapporteur Group).  The Study Group Chairman sends the
   ITU-T list of delegates by email to the Working Group chair, with a
   copy to the Area Directors, and also to the Study Group.  Note that,
   according to IETF process, opinions expressed by any such delegate
   are given equal weight with opinions expressed by other working group
   participants.

If Sun Microsystems or Microsoft sends someone to authoritatively
speak on behalf of a protocol that is documented but otherwise
entirely under control of that entity, an IETF may consider
documenting its existance in an "informational" document.  The same
applies to ITU-T sending someone to authoritatively speak on behalf of
their work.

Any such document is considered to be encumbered by intellectual
property restrictions and therefore is treated appropriately.  An IESG
may consent documenting the existance of an outside effort and IETF
WGs are still free to completely ignore it.  This may be the case with
ASON and other ITU-T requirements documents where the ITU-T has stated
some requirements and where the IETF may choose to document the
existance of the ITU-T requirements but is free to ignore any or all
of them.

Part of the reason for the turf (not really jurisdictional) issue is
the overlap that occurs when considering TDM over MPLS or IP.  A
fundamental difference in the way the ITU-T and IETF think about this
is the ITU-T sees this as a new layer under the TDM network and the
IETF sees this as a means to support legacy TDM service.  As with the
IP QoS topic of the mid-1990s, what matters is what the providers want
to do with their networks and what proves profitable to do.  If the
view that TDM over MPLS just serves to accommodate a declining TDM
customer base proves accurate, then the IETF would be wise to ignore
much of what the ITU-T is doing in this area.

Back to the original question posed by Bod Braden.  It might be
possible for IANA or the RSVP experts (Bob) to go to a WG for a
recommendation on any given request.  Since RSVP is highly extensible
the WG could make a recommendation that a code point for an object be
added but that the WG's concensus is that the protocol is of no
interest to the IETF.  As long as code point space is plentiful a
portion of the number space could be set aside for such allocations.
[This may be the same as Bob'd Surgeon General's warning idea.]

Curtis