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(_at_)att(_dot_)com]
Sent: Thursday, January 23, 2003 7:49 PM
To: iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)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