The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <3E3079AF.3010ED7C@lucent.com>, Stephen Trowbridge writes:
> 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



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


> 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.  Rathe
> r
> > 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 tha
> t
> > 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
>