Summary [was: RE: Starting a discussion on graceful shutdown]

["Zafar Ali" <[e-mail]>]

Hi Adrian, 

Thanks for putting this email together. In the following I have tried to
summarize the discussion we had on this thread and next steps. 

Thanks

Regards... Zafar 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 10:39 AM
> To: [e-mail]
> Subject: Starting a discussion on graceful shutdown
> 
> Hi,
> 
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace
> ful-shutdown-00.txt was discussed at the meeting in 
> Washington DC, and one of the questions raised was whether or 
> not we already had (multiple!) mechanisms capable of 
> performing the function described in the draft.
> 
> Kireeti quite rightly suggested that we step back and make 
> sure we understand the requirements. This is my take on those 
> requirements and I would appreciate it if the authors of the 
> draft joined in and other people on the list commented.
> 
> We wish to manage a link that needs to be taken out of 
> service in some way (data plane and/or control plane will be 
> disrupted). The link concerned has active LSPs and we wish to 
> offer upstream LSRs (in particular the ingress) the 
> opportunity to use make-before-break to re-route the LSPs.
> 
> In order to achieve this, we need to communicate to the 
> upstream nodes. Should we choose signaling or routing? Are 
> there benefits that mean we should use both, or should we 
> limit to just one?

Yes, we need both. 

> 
> There is another aspect to be considered. Should we also 
> attempt to protect new path computations from selecting the 
> link that will be taken out of service?

Yes, 

> 
> How should we consider the case of a node (data plane and/or 
> control plane) being taken out of service? 

Yes, 

>Is a node simply a 
> collection of links?

Yes, during graceful shutdown period. 

> 
> If a component link of a bundle is being taken out of service 
> (and assuming other component links are available) is this 
> just an issue for the adjacent nodes or does it need to be 
> communicated more widely? 

Let head end do the mb4b, 

> If the downstream node decides to 
> take the component link out of service, how does it inform 
> the upstream node?
> 
> Does it matter whether it is the control plane or the data 
> plane that will be taken out of service?

Yes, if data plane is going OOS, we are loosing traffic and motivation
behind mb4b to reduce traffic hit is lost. 

> 
> Opinions please.
> 
> I would like to see these issues and their answers captured 
> clearly in a requirements section of any draft. Would the 
> authors of draft-ali-ccamp-mpls-graceful-shutdown-00.txt
> be willing to take that on even though the end result might 
> be that procedures other than those they suggest will be selected?

Sure, we plan to revised the ID based on this survey as well as comments
from the WG for the upcoming IETF. 

Thanks again Adrian for your suggestion and putting this together. 

Thanks

Regards... Zafar

> 
> Adrian
> 
>