Re: Polling for new WG I-Ds

[Igor Bryskin <[e-mail]>]

  Hi,
   
  Yes to all three.
   
  Igor
   
   
  ----- 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 
> 
> 




 		
---------------------------------
Do you Yahoo!?
 Next-gen email? Have it all with the  all-new Yahoo! Mail Beta.