RE: Last Call: CR-LDP Extensions for ASON to Informational

["Lin, Zhi-Wei (Zhi)" <zwlin@lucent.com>]

Hi Jerry,

I'm not sure how long you've followed the entire GMPLS and ASON work, but I'm assuming here that you weren't part of the original discussions over the last 1.5 to 2 years on this matter. That's understandable as this wasn't your original area of interest.

However, if you talk with some folks involved since the beginning, you would realize (and also reading Steve's email on the history, or simply going back to the email archives in both MPLS and CCAMP) that
(a) ITU-T tried to get the work done in IETF (I believe Steve mentioned Oct. 21, 2001)
(b) IETF never actually started/initiated work to fill these gaps. So a set of individuals who happens to attend IETF, OIF and ITU decided that they would work towards a solution
(c) This solution was submitted into IETF, OIF, and ITU -- with clear intention of trying to get feedback from the "true" RSVP experts
(d) I (and Bala) created I-Ds in IETF (Bala actually started this I think sometime in early 2002? -- Bala you can confirm or correct -- while I submitted my I-D in June 2002)
(e) These documents were never taken seriously (This is the first email I sent: http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00918.html -- but of course no one responded)
(f) ITU-T requests which were publicly presented in CCAMP meetings by Wesam and Steve (see Steve's email to see how many requests were made) were never taken seriously

The ITU-T delayed their process by several months in order for RSVP experts (I guess Bob Braden would call folks who's done this work "non-RSVP experts") to review. Of course no comments were ever provided by the "true" RSVP experts.

Several individuals tried very hard to try and get a good relationship and collaboration going amongst the three organizations. The break-down is not for lack of trying or exposing the work to the RSVP experts.

As such, although I agree that the original intent of all the individuals who came into this work expecting to collaborate and do the work in IETF CCAMP WG, the actual situation is very much different, and is a result of certain members of the CCAMP WG community deciding not to bother with paying attention to the work. Again I can understand the perception that you get since you weren't involved from the beginning. But a casual perusal of the email archives (too much work for me, if you're interested you should take a look at the history first) would give you a much better and accurate history of the discussions (see http://ops.ietf.org/lists/ccamp for the CCAMP email archive, and http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html for the MPLS email archive).

Thanks
Zhi


-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
Sent: Thursday, January 23, 2003 7:49 PM
To: iesg@ietf.org; ietf@ietf.org
Cc: Ash, Gerald R (Jerry), ALABS; Stephen Trowbridge; David Charlap; Loa
Andersson
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational


Parallel discussions on the thread 'IANA considerations for RSVP' (postings by Steve Trowbridge and David Charlap) and this thread (Loa Andersson) have shed some light on a) how extensions to GMPLS protocols to satisfy ASON requirements shifted from IETF to ITU, and b) the consequences:

steve> - On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding
steve>   the gaps that had been identified between the ITU-T requirements (sent
steve>   earlier) and what seemed to be implemented by the GMPLS protocols.
steve>   Specifically,
steve>   1. Call & Connection separation, e.g., a call provides the service
steve>      relationship, which may support connection operations as part of a 
steve>      call. 
steve>   2. Additional error codes/values, for example, for connection rejection
steve>      (invalid connection ID). 
steve>   3. Restart mechanisms: Depending on the introduction by the ITU of 
steve>      additional control plane resiliency requirements, enhancements of the 
steve>      protocol (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be 
steve>      required. 
steve>   4. Protocol enhancements in CR-LDP for support of crankback capability 
steve>      from intermediate nodes. 
steve>   This liaison was presented in the Minneapolis IETF meeting during the 
steve>   ccamp working group and posted on the IESG web site. The liaison requested
steve>   assistance in closing these gaps and invited input from IETF on our work
steve>   in ITU-T.

I recall this discussion and understood that the intent was to have extensions made by CCAMP to GMPLS protocols based on these ASON requirements and thus close the 'gaps'.

steve> - At the April/May 2002 meeting of ITU-T Study Group 15 meeting,
steve> contributions were considered to close these gaps, resulting in text for
steve> draft Recommendations G.7713.2 (our rsvp-te document) and G.7713.3 
steve> (our cr-ldp document). Again, we sent a liaison (dated May 10, 2002) to ask
steve> for comments on our draft Recommendations (made available on the ftp site),
steve> to request alignment, and to ask for IANA code point assignments. To quote
steve> from that liaison:
steve> "Please consider including the proposed solutions provided in G.7713.2 and 
steve> G.7713.3 to update the existing GMPLS signaling work in support of ASON 
steve> requirements.

I think this is consistent with the understanding that the intent was to have extensions made by CCAMP to GMPLS protocols based on the ASON requirements and thus close the 'gaps'.

steve> To hear now that someone thinks that the ASON work in ITU-T is some kind
steve> of secret end-run around IETF, and not involved with or related to the
steve> work being done internally in IETF is absurd. At every stage of the work,
steve> IETF was kept informed of the work and invited to participate. At the
steve> invitation for help to address the additional ITU-T requirements, there
steve> was no response. As ITU-T progressed this work and invited further comments
steve> and alignment of the base GMPLS protocols, again no response. And to the
steve> final pleas for comments and codepoint assignments, no response.
steve> ...
steve> After some private communication with the Area directors, we received some
steve> advice that one tool that might be used to finally get the IANA codepoint
steve> assignment complete would be to publish what we were doing in ITU-T as
steve> informational RFCs. This is the stage we are at today, and given the
steve> history I describe above, I do not think anybody can say that we are
steve> at this point because any of us did not do everything possible to
steve> do this work (a) in IETF, with the initial communication of requirements;
steve> or (b) in cooperation between ITU-T and IETF, once this work had
steve> progressed in ITU-T.
steve> 
steve> But this is all water under the bridge. We are at the point of trying
steve> to get some codepoints assigned for ITU-T documents we are trying to
steve> complete. Nobody should say "no" at this point because they think we
steve> didn't try to work this IN or WITH IETF first. It should be clear to
steve> all that this is not the case.

I can understand the frustration in not getting cooperation and follow-up on the ITU/ASON requirements.  However, the 'private communication with ADs' left most of us in the dark as to what was (is) going on.  

The concern still is (drawing from posts by Loa Andersson and David Charlap):

loa> The consequence of approving the drafts will be that the extensions
loa> by OIF and ITU will be approved by the IETF. I'm not sure that this
loa> has been in the open.

david> I'm far more concerned with non-IETF groups (like ITU, ATM Forum and 
david> others) deciding to develop their own incompatible extensions without 
david> even informing any IETF groups of their actions.
david> Groups like these should not be extending IETF protocols without 
david> consulting with the relevant IETF working groups.  Otherwise 
david> we end up with extensions that duplicate existing IETF functionality, 
david> don't coexist gracefully, and/or break interoperability.  And if these 
david> extensions become popular in products, the IETF will be forced to 
david> include them in the standards in order to prevent future IETF work from 
david> breaking them.

I agree.  

To give one concrete example of the consequences of not doing as David suggests: Now that the subject ID http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-crldp-ason-ext-02.txt has been approved, the crankback TLV defined in Section 4.3 becomes the de-facto crankback TLV, no?  Further discussion/debate in IETF on other proposals (e.g., as proposed in http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-04.txt) becomes moot.  This doesn't seem to be the right process to arrive at this technical conclusion.

Jerry Ash