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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%