Re: GMPLS Protection and Restoration Design Team - Report

[Dimitri.Papadimitriou@alcatel.be]

hi

from the ccamp wg effort perspective, i think that the 
section 5.5.2 Dynamic LSP Restoration in the analysis 
i-d addresses your concern, it was not within the scope 
to preclude such capability, thus may i ask here what has 
in the current set of ccamp i-d implied such deduction, 
this may help us for further clarification

thanks,
- dimitri.

Vikram Anantha wrote:
> 
> It appears that the drafts produced by the TEWG design team and the
> GMPLS protection and restoration design team refer mainly to
> protection/restoration schemes where the protection capacity is either
> pre-calculated or is pre-established. This precludes dynamic restoration
> schemes like "dynamic mesh restoration".
> 
> IMHO this needs to be spelled out. If it has already been spelt out, I
> would appreciate a pointer to it. This would also be inline with the
> "Expected Document # 3" mentioned below.
> 
> Vik
> 
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Monday, November 11, 2002 7:39 AM
> To: ccamp@ops.ietf.org
> Subject: GMPLS Protection and Restoration Design Team - Report
> 
> ccamp'ers,
> 
> Here below the report of the GMPLS protection and restoration design
> team:
> 
> Team goals were defined as follows:
> 
> Starting point Protection & Restoration produced by the TEWG
> Design Team. The produced functionality should satisfy these
> requirements; content that goes beyond these requirements or
> doesn't meet some of them should be called out so that the
> wg can re-evaluate.
> 
> Expected documents:
> 
> 1. Produce a terminology document, delivering a decoder ring to
>    translate to terminology in current drafts as well as the TE
>    WG document.
> 
> 2. Produce an (interim) analysis document, comparing and contrasting
>    approaches (i.e., the above drafts, published and ongoing work
>    at the ITU/T1-X1/...)
> 
>    note: from this perspective a decoder table on the current
>    methodologies/mechanisms may be additionally delivered in (1)
> 
> 3. Produce a functional spec delineating
> 
>    - What's in scope, out of scope, what's for future study, which
>    of the TEWG reqts have been met, which not, and what goes beyond.
> 
>    - This document should detail the overall approach objects/
>    procedures/... needed in a protocol-independent fashion
> 
>    note: point one will be translated by delineating content and
>    definition included in (1)
> 
> 4. Produce protocol specification
> 
>    4.1 Produce a document detailing the changes for RSVP-TE
> 
>    4.2 Produce a document detailing the changes for OSFP-TE and IS-IS-TE
> 
> Timeline:
> 
> - Ietf53 (march'02) both were discussed in minneapolis 1. (i.e.
>   the terminology i-d) had become upon community agreement wg
>   i-d
> 
>   note: nearly on time with the initially expected timeline for
>   this first step
> 
> - Ietf54 (july'02) decision upon closing content to be
>   included in the analysis i-d two weeks after the meeting
> 
>   => A version -02.txt of the analysis i-d had been submitted
>      end of august. Also a functional specification has been
>      delivered at the same time (had not been submitted on time
>      to be discussed during ietf54 meeting)
> 
>   note: compared to the initially expected timeline, this was
>   delayed by one ietf meeting
> 
> - Ietf55 (nov'02) decision upon analysis and signalling
>   functional specification to be discussed, once agreed
>   work on 4.1 and 4.2 should started first discussion to
>   be expected for Ietf56 (stabilizing protocol specification
>   should be achievable during '03 time it would be take
>   greatly depends upon the what's in/what's out/what's for
>   the next step decision)
> 
>   note: compared to the initially expected timeline, this was
>   delayed by two ietf meetings
> 
> Intermediate Conclusion:
> 
> - Still some work to be produced in particular with respect
>   to the protocol specification (expectation within a year
>   for a first phase)
> 
> - Delay can be explained in several ways 1) over time, the
>   more we get into the details the more time it took to
>   described and analyze the situation - as such the fact
>   the scope is closed now will help in achieving a tolerable
>   complexity level and allow for a first phase completion 2)
>   the timeline was probably too tight in order to allow for
>   any delay which has been accumulated after ietf'53
> 
> See we in atlanta,
> 
> thanks,
> - dimitri (for the p&r dt).

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