[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Polling for new WG I-Ds
Please see in line.
----- Original Message -----
To: "Adrian Farrel" <email@example.com>
Cc: <firstname.lastname@example.org>; <email@example.com>
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.
> > has been updated by the authors to provide further details and
> > clarification.
> - ok -
> - 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
> 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.
> > 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