RE: ASON RSVP-TE draft to WG doc

["Varma, Eve L (Eve)" <evarma@lucent.com>]

Hi Kireeti,

I do not think now is the right time for draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt to become a CCAMP WG document, as the current draft is leading us along a path of divergence among specifications for ASON extensions - something I view as not in our collective interests. Therefore, my input at this point is "no".

Three technical issues have been under discussion on the mailing list that are related to draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt, which is using different approaches:
o Treatment of ResvErr and ResvTear messages during the setup phase, as specified in Rec. G.7713.2 (i.e., "fatal flaw")
o Usage of GENERALIZED_UNI object as specified in ITU-T G.7713.2 and its equivalent in G.7713.3, which was derived from OIF UNI 1.0 IA
o Support for SPC using G_UNI as specified in ITU-T Rec. G.7713.2 and G.7713.3 

Of these items, only for the treatment of ResvErr and ResvTear messages has there been any statement made suggesting a technical flaw.  The "fatal flaw" characterization was first raised, as I recall, during Jan. '03 as part of the discussion of code point assignments, where it was suggested that there was an incompatibility in the treatment of ResvErr and ResvTear messages in the 3474 text.  As a result, some text was removed.  It is now eight months since that time, and to date, no one has given a full technical description of the issue either via email to ccamp, or via a liaison statement to ITU-T.  Kam Lam, the Rapporteur of Q.14/15 has made a specific request for someone to identify the detailed message flows as defined in ASON, and point out which message sequence causes the problem.  If there is a "fatal flaw", we need to provide the details to ITU-T as soon as possible so that they can make the necessary corrections to G.7713.2 via a Corrigendum.  Let's get the facts!
  on the table rather than just reiterating this assertion so that, if there is a problem, something can be done about it.

In terms of G_UNI and SPC using G_UNI, I think a bit of context is useful, as these were discussed and agreed to by a broad range of people and companies across the industry over the past few years.  There has never been any claim of a technical flaw that "breaks GMPLS".  These ASON extensions were not derived independent of participation from IETF experts.  As has been noted within email discussions from last Jan. '03 when these issues were raised, many (approximately 10+ or so) of the major players from the CCAMP and MPLS WGs were contributing to the OIF LDP and RSVP specs for UNI 1.0.  Quite a few have also been active in ITU-T, which has consistently communicated both ASON requirements and any potential solutions for feedback/input from IETF experts.  This joint participation across standards and industry fora enabled a much higher degree of visibility and critical mass of expertise to work on and impact ASON signaling extensions.  In particular, the GENERALIZED_UNI obje!
 ct received extensive discussion among experts cross-participating in multiple fora, and is included in the resultant agreed specifications:

o  Alignment on OIF-UNI-1.0 during 4Q01, with 78 companies approving the document at Principal Ballot.  (Actually, many of the individuals who are raising objections to G_UNI are also on the contributor list of the OIF document and their companies voted "Yes" on the UNI 1.0 Principal Ballot.)  
o  Consensus for Approval of ITU-T G.7713.2 and G.7713.3 March '03, using the code point assignments from RFCs 3474, 3475, and 3476.  (The companies of several of the individuals raising objections who are members of the ITU-T also voted affirmatively to Consent G.7713.2 and G.7713.3.)  I'd note the process the ITU-T uses allows for technical objections to be raised both during initial "Consent" and well as on the way to actual Approval.  No comments or technical objections were raised to "Consent" of these Recommendations during the Jan. '03 meeting of ITU-T SG 15 (nor by the 189 member states, over 650 sector members, or 49 associate members who had the opportunity to review the text thereafter).  

Thus, at this time running code exists and interoperable implementations are available and have been publicly demo'd that use G_UNI.  With draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt, we are consciously deciding to take a different path for the aforementioned areas in this regard.  The question I think we need to ask ourselves is whether coming up with alternative approaches to working solutions that have been previously specified - introducing divergence among specifications for ASON extensions - is in the best interests of the IETF community and the industry. 

Best regards,
Eve