Re: 答复: Polling for new WG I-Ds

[[e-mail]]

hi - 

on point 1) before thinking about undo's & redo's the first issue is to 
consider that during the "import" of the allocated resource -> CP state 
you may have a failure at that point in time in the process -

on point 2) in case of CP failure - including unresponsive CP instance - i 
don't see how you may trigger the CP to "export" that state

thanks,
- d.





李晗 <[e-mail]>
25/08/2006 02:53
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "'Dan Li'" 
<[e-mail]>
        cc:     "'Adrian Farrel'" <[e-mail]>, 
<[e-mail]>, <[e-mail]>
        Subject:        答复: Polling for new WG I-Ds



Hi,

From our perspective, we think the following requirements are better to be
considered:

1) In case there is a problem after we do MP->CP movement, we would like 
to
be able to return to the previous state. So the MP->CP procedure must be
equipped with a back-out procedure so that we can reverse the procedure.
This "undo" function allows transfer of control from CP->MP.

2) In the event of a CP failure (such as the failure of the control plane 
at
a node), we may wish to control the LSP and this requires that the LSP is
transferred from the CP to the MP.

Regards, 

Lihan

*****************************************************

Li Han, Ph.D.

R&D, CHINA MOBILE COMMUNICATIONS CORPORATION

Tel: [phone] ext. 3092

Fax: [phone]

MOBILE: [phone]

*****************************************************

hi - 

see inline





Dan Li <[e-mail]>
Sent by: [e-mail]
21/08/2006 04:01
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel 
<[e-mail]>
        cc:     [e-mail], [e-mail]
        Subject:        Re: Polling for new WG I-Ds


Hi Dimitri,

Please see in line.

Regards,

Dan

----- Original Message ----- 
From: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
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.t

xt

> 
> - 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.

[dp] ok so what's left for this doc ? concerning the MP-driven failover - 
imho nothing
 
> 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.

[dp] this is what i thought

> 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. 

[dp] concerning CP->MP input you provided would be helpful to have 
carrier's 
speaking for themselves - now there is indeed a side question shall CCAMP 
take
care about operators that want to step back from GMPLS or more generally 
any
control plane technology (usually concern is how to move forward not 
backward)

 
> 
http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-0

4.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 
> 
>