Yes to all three.
----- Original Message -----
From:
To: "Adrian Farrel"
Cc: ;
Sent: Thursday, August 17, 2006 6:32 AM
Subject: Re: Polling for new WG I-Ds
> adrian - see in-line
>
> Adrian Farrel wrote:
> > Hi,
> >
> > As discussed in Montreal, we need to poll for a couple of new WG drafts.
> >
> >
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt
>
> > has been updated by the authors to provide further details and
> > clarification.
>
> - ok -
>
> >
>
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt
>
> - guess it is v03.txt ? -
>
> > has been updated since the version discussed in Montreal.
>
> i am ok in investigating the MP->CP but i have two concerns that imho
> should deserve more specific attention to maintain consistency wrt to
> CP->MP
>
> section 2.2: if control is lost for an LSP (during CP failure) how can it
> be possible transfer that LSP from the CP -> MP ?
[dan] Yes, there is a problem if we still want to use the control plane to do the
CP->MP transfer. Unless the transfer is based on the predetermined policy, MP
takes the control of the LSP resource directly (no signaling required), but this way
should not be discussed in CCAMP.
>
> section 4.4: why the document assumes that both MUST be supported ? in
> part. concerning the CP->MP if one does
implement current GMPLS signaling
> restart/recovery why shall this be mandated ? in brief, the document shall
> take into account existing mechanisms and prevent overlaps (with existing
> GMPLS mechanisms)
>
[dan] I think the CP->MP should not be the mandatory requirement.
> hence, it is strongly suggested to identify conditions when such CP->MP is
> required (and not an alternative to existing CP mechanisms) b/f
> progressing that part
>
[dan] In order to make the carriers' life easy, when we provide the MP->CP
conversion feature, the reverse procedure (CP->MP) may also is needed just
simply in case the carriers want to withdraw their previous decision, and
they also feel more comfortable with this "undo" function; In order to achieve
this, we should have the working control plane.
> >
>
http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt
>
> > has been updated as Zafar says in his previous email.
>
> informational imho - in its current version
>
> - not sure to understand why the PathErr/Notify can be processed by the
> head-end only (what about segment recovery and stitching case) - why only
> MBB is possible upon reception (pls use E2E recovery/Segment recovery
> capabilities as you address GMPLS networks)
>
> - compared to path-reopt, error description is identical for the TE link
> case which leads to the following point - if errors code/value are the
> same how to distinguish them (assuming that the query procedure described
> in path-reopt is used during the setup of that LSP) ? - comment is more
> for the path-reopt draft than yours but since there is an overlap ... it
> must be addressed in a way or another
(note that when fully head-end
> driven operations look similar but there is a major difference role of
> timing and severity of the error code/value)
>
> - in case shutdown of a protected component link (of a bundle) is
> initiated why can't link protection be used ?
>
> > Please send yes or no for these I-Ds.
> >
> > Reasons and opinions are also welcomed.
> >
> > Thanks,
> > Adrian
>
>