Re: Last Call: CR-LDP Extensions for ASON to Informational

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(_at_)carmen(_dot_)ipv6(_dot_)cselt(_dot_)it, which is a sublist 
of ietf(_at_)ietf(_dot_)org(_dot_) Not all messages are passed. Decisions on 
what to pass are made solely by Raffaele D'Albenzio.


-- 
Papadimitriou Dimitri 
E-mail : dimitri(_dot_)papadimitriou(_at_)alcatel(_dot_)be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou(_at_)psg(_dot_)com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361