RE: Next steps for draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....

["Zafar Ali \(zali\)" <[e-mail]>]

Dear Dimitri- 

Thanks for your comments and sorry for the delay in replying. Please see
in-line. 

Thanks

Regards... Zafar  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 
> Sent: Wednesday, March 07, 2007 7:28 PM
> To: Zafar Ali (zali)
> Cc: Adrian Farrel; Anca Zamfir (ancaz); [e-mail]; 
> Brungard, Deborah A, ALABS; Jean Philippe Vasseur (jvasseur); 
> [e-mail]
> Subject: Re: Next steps for 
> draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....
> 
> zafar -
> 
> o) would it be possible to sum'up changes you have been 
> provided since so far ?
> 

Dimitri- 

The delta was to mainly addresses comments received. The major comments
were (quoting from respective email): 

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

How this comment is addressed:

Re: segment recovery and stitching case, definition of the node that can
perform GS procedure has been extended to include Ingress LSR of an
S-LSP. See enclosed slides for details.

Re: why only MBB is possible upon reception. 

Text in the new version is modified such that it allows the following- 

- Graceful shutdown may be exercised using make-before-break or FRR/
segment recovery procedure. 
- When PLR/ branch node receive a Path Error with Graceful Shutdown
indication, 
  	o It MUST forward the Path Error to the Ingress node.
  	O Based on a local decision, PLR/ branch node MAY trigger FRR/
segment recovery.

"- in case shutdown of a protected component link (of a bundle) is 
initiated why can't link protection be used ?"

How this comment is addressed:

Based on a local decision, PLR/ branch node MAY trigger FRR/ segment
recovery to recover from failure of a component link. 

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

This ID inherits the Ingress behavior from RFC 4736, which says, "Upon
receiving an RSVP PERR message with Error code 25 and Error sub- code 7
(Local link maintenance required) or 8 (Local node maintenance
required), the Head-end LSR SHOULD perform a TE LSP reoptimization". 
This drafts extends the handling of this error code/ sub-code at PLR/
branch node (which includes the case where  ingress node is PLR/ branch
node). IMO no need for adding a new perr subcode.  

> o) would it be possible to clarify the following statement
> 
> "- Graceful shutdown mechanisms are required to address TE LSPs 
>    spanning multiple domains, as well as intra domain TE LSPs. "
> 
> afaik you don't shutdown LSPs but Links - right ?

This is correct. We will change the wording to make it clear. 

> 
> thanks,
> -d.
> 
> 
> 
> 
> 
> "Zafar Ali \(zali\)" <[e-mail]>
> Sent by: [e-mail]
> 02/03/2007 00:41
>  
>         To:     "Adrian Farrel" <[e-mail]>, 
> "Brungard, Deborah 
> A, ALABS" <[e-mail]>, Dimitri 
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <[e-mail]>, "Jean Philippe Vasseur 
> \(jvasseur\)" 
> <[e-mail]>, "Anca Zamfir \(ancaz\)" <[e-mail]>
>         Subject:        Next steps for 
> draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....
> 
> 
> Hi Adrian, Deborah, Dimitri, and campers- 
>  
> As we mentioned at the last IETF meeting, 
> http://www3.ietf.org/proceedings/06nov/slides/ccamp-17/sld1.ht
> m, we have addressed all outstanding comments, except the 
> following comment from Dimitri, related to this ID. Should 
> you have any further comment, please share. 
>  
> The only remaining comment that is not closed is "should this 
> ID be informational or standard track". IMO the ID defines a 
> new error-subcode and some specific behavior, and should be 
> standard track. Can you please comment on this. 
>  
> The ID has been stable for quite some time and following the 
> closure of the above, we would like to request last call. 
>  
> Thanks
>  
> Regards... Zafar  
>