jerry, all, very simply i would imho recommend that involved parties (re-)consider your proposal "Would it be worthwhile to somehow 'package' the needed ASON extensions into a proposed GMPLS upgrade and presented to CCAMP as such?" this is the only way i can see (today) to achieve a (hopefully) satisfactory result from both involved sides. yes, jerry i agree with you it is imho the right way to handle this. thanks, - dimitri. "Ash, Gerald R (Jerry), ALABS" wrote: > > Zhi, > > > (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) > > Reminder, I responded to your email on June 18, very shortly after you posted (my email to you is attached below). That I did this off the list was probably a mistake. We (you, your co-authors, Adrian and I) then had a prolonged exchange of emails about the draft. Adrian sent you extensive comments on the draft highlighting concerns, suggesting text, and pointing out nits. That you have a reasonably long list of acknowledgements and contributors suggests that the draft was not ignored. > > As I commented in the attached email to you, "Would it be worthwhile to somehow 'package' the needed ASON extensions into a proposed GMPLS upgrade and presented to CCAMP as such?" I still maintain that this would be the correct way to handle this: bring the requirements to CCAMP as a requirements draft, thrash them out, and get the necessary extensions adopted in CCAMP. Rather, the ITU has developed protocol extensions for GMPLS, something outside the charter of the ITU I believe. > > Jerry > > -----Original Message----- > From: Ash, Gerald R (Jerry), ALASO > Sent: Tuesday, June 18, 2002 12:58 PM > To: 'Zhi-Wei Lin' > Cc: Ash, Gerald R (Jerry), ALASO; 'Adrian Farrel' > Subject: RE: new draft: GMPLS for ASON > > Hi Zhi, > > > I've uploaded a new draft covering the GMPLS usage and extensions to > > support the ASON requirements. This document proposes appropriate > > extensions towards the resolution of additional requirements identified > > and communicated by the ITU-T in support of ITU's ASON standardization > > effort, and only provides the extensions for RSVP-TE signaling. Among > > the major extensions include support for the concept of "call", as well > > as support for setting up soft permanent connections. > > > > http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-00.txt > > Looks good. > > I've attached some excerpts below from the (unpublished) IETF-54/CCAMP meeting minutes. These also identify crankback, restart, etc. as 'gaps' needing to be filled. I guess most of these are being worked on, including restart and crankback http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-03.txt (Adrian is currently providing a significant extension for the 04 version of the crankback draft). > > Would it be worthwhile to somehow 'package' the needed ASON extensions into a proposed GMPLS upgrade and presented to CCAMP as such? > > Your comments/suggestions are appreciated. > > Thanks, > Regards, > Jerry > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Steve Trowbridge > > Outlined a variety of "gaps" in the current work: > - Call and connection separation > - Additional error codes/value > - Restart mechanisms > - Support for crankback > - Support for soft permanent connection > > See proceedings for details. > > Eric Mannie: Referring to slide "Identified Gaps". Gaps seem to be > very small. Most of the points are solved, can be easily solved, or > are in the process of being solved. > > Trowbridge: This was a preliminary scan. Further review, might turn up > more issues. Technologies are similar, so lets identify and minimize > gaps. > > Dimitri: ITU requirements precede much of IETF work. Preliminary > discussions indicate that the current gaps are covered by existing > protocol work. Areas where additional work will be required are > probably minimal, but need to be looked at. IETF may gain final > improvements by looking at ITU work. > > Yong Xue: ITU is working on v2 ASON document so more things could turn > up as "gaps". Further communication between ITU and IETF should > continue. > > Trowbridge: Technology will evolve within both organizations. Should > expend effort to make sure that they evolve together. > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > % Osama Aboul-Magd -- draft-aboulmagd-ccamp-call-conn-separation-00.txt. > > Draft addresses one of the issues that Tolbridge highlighted in his > talk - call and connection control separation. > > Kireeti: There is an explicit statement from ITU requiring this. > There is nothing in the charter about this. This is good stuff. Ron > and I will go through a charter revision with Ads and discuss putting > this in the charter. Also need to address other gaps that were raised > by ITU. > > Scott: When you propose to add something to WG, it would be helpful to > state where it fits in the existing charter OR how and why charter > should be extended. > > Eva: I think that it fits into the character as a requirement to the > signaling protocols. > > Scott: OK - that is a good clean explanation that might save chairs > some time. > > Yong: I second Eva's comment. > > Kireeti: Need to figure out how to address other issues as well. > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > _______________________________________________ > This message was passed through ietf_censored@carmen.ipv6.cselt.it, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio. -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361