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

["Richard Rabbat" <[e-mail]>]

Hi Zafar,
First, I'd like to point out that your draft has expired; thought you might
want to put a quick version up.
Some comments inline and more generally about the draft.
Thanks a lot,
Richard.
--
- in the text, you say: MAY NOT. This is not defined. 

- Discussing PCE in this draft seems to be out of place. This draft is sent
to ccamp and should not specify what a PCE node has to do.

- This is especially confusing since you say that a PCE is receiving RSVP
Path error messages. This implies somebody sent it to the PCE. But you have
defined communication from the node where shutdown occurs to the ingress.
How does the PCE know about this message?

- You talk in the draft about FRR but FRR does not apply to all types of
switching in GMPLS. Please reflect that in your text to say: "In the case of
PSC, ..."

- You mention FSC, LSC and PSC. Is it your objective not to address L2SC and
TDM?

- I'd also like to ask you how you decommission a bundle? Does the headend
of that bundle have the responsibility of telling each headend of each
component about the shutdown?
E.g. let's say I'm shutting down a link in a SONET box that has a
server-layer circuit (say an STS-3c) that is carrying Ethernet as the client
layer. Who tells the Ethernet "headend" about the shutdown?

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Zafar Ali
> Sent: Tuesday, February 15, 2005 10:34 PM
> To: 'Adrian Farrel'; [e-mail]
> Subject: Summary [was: RE: Starting a discussion on graceful shutdown]
> 
> 
> 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. 
> 
Can you explain to me the justification for both? 
I don't think there is no need for routing extensions, since the routing
protocol will stop advertising decommissioned links. 

Can you also explain the difference between your method and the available
SONET mechanisms for shutting down resources?

In section 4, you talk about OSPF/ISIS. Do you mean OSPF-TE/ISIS-TE? 

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

There is a balance between (1) telling ingress LSR's vs. (2) ingress LSR's
receiving notification through usual updates. Authors need to justify need
and advantage for (1).
> 
> > 
> > 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
> > 
> > 
> 
>