[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: GMPLS Protection and Restoration Design Team - Report
[ post by non-subscriber. with the massive amount of spam, it is easy to miss
and therefore delete posts by non-subscribers. if you wish to regularly
post from an address that is not subscribed to this mailing list, send a
message to <listname>-owner@ops.ietf.org and ask to have the alternate
address added to the list of addresses from which submissions are
automatically accepted. ]
Hi all,
This is my second attempt at trying to contribute to the protection and
restoration documents. It appears that the ccamp mailing list thinks my
mail is a virus and filters it out. Maybe I need to ratchet up my
rhetoric to fit in :).
Part of my confusion is probably trying to understand the scope of the
terminology document
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-term
inology-01.txt and the analysis document
http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-reco
very-analysis-03.txt.
Section 5.5 of the analysis document talks about "Restoration Schemes"
and mentions Dynamic LSP Restoration like you pointed out. However
Section 4.6 of the terminology document talks about "Recovery Types" and
only mentions M:N type where M and N are pre-established. So maybe
Section 4.6 needs a new "Recovery Type" a M:N where N is dynamically
calculated?
Also on closer reading of TEWG's RFC 3386, I realized that this RFC
definitely does not preclude dynamic restoration. It allows for it in
the path and local restoration sections. So I will stop posting this to
both mailing lists.
Thanks,
Vik
-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Wednesday, November 13, 2002 9:41 PM
To: Vikram Anantha
Cc: ccamp@ops.ietf.org; te-wg@ops.ietf.org
Subject: Re: GMPLS Protection and Restoration Design Team - Report
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