[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GMPLS Protection and Restoration Design Team - Report
hi, i thought i had already responded to the first point
on dynamic restoration issue (in brief it is within the
scope), please refer to my previous e-mail, now concerning
the difference between a scheme and type, first it is
orthogonal to previous point and secondly i suggest you
take at the section 5.4 where the definition is provided
"Section 4.6 of [CCAMP-TERM] defines the basic recovery
types. [..] a recovery scheme is defined as the combination
between different ingress-egress node pairs of a set of
identical recovery types." take it here as a structural
way to describe shared meshed recovery;
hope this clarifies,
- dimitri.
Vikram Anantha wrote:
>
> [ 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
--
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