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