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

[[e-mail]]

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 [e-mail], which is a sublist of [e-mail]. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.

-- 
Papadimitriou Dimitri 
E-mail : [e-mail] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [e-mail]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: [phone] - Home: [phone]