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

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

Dear Richard, 

Please see my reply in-line.

Thanks a lot for your review and detailed comments, 
 
Regards... Zafar
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Richard Rabbat
> Sent: Thursday, February 17, 2005 5:35 PM
> To: 'Zafar Ali'; 'Adrian Farrel'; [e-mail]
> Subject: RE: Summary [was: RE: Starting a discussion on 
> graceful shutdown]
> 
> Hi Zafar,
> First, I'd like to point out that your draft has expired; 
> thought you might want to put a quick version up.

You will see a copy of draft reflecting all comments received thus far petty
soon. 

> Some comments inline and more generally about the draft.
> Thanks a lot,
> Richard.
> --
> - in the text, you say: MAY NOT. This is not defined. 

Good catch, in the new version you will see revised text. 

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

Via PCC, 

There are places where document lists set of roles that any entity computing
a path should follow, i.e., Ingress node, intermediate nodes performing ERO
extensions or PCE. Certainly specification of (related) PCE-PCC
communication is beyond the scope of this document and in the revision we
have clearly stated that. 

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

Done, 

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

No, nothing intentional to avoid L2SC, TDM. We have modified the text
accordingly. 

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

Yes, and ID talks about this. When all component links of the bundle are
being decommissioned, its like graceful shutdown of a TE link. However, if
only a subset of component links are decommissioned, procedure for graceful
shutdown of the component links applies (as listed in section 4.2 of the
last version of the ID). 

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

The box/ node upstream to the link under graceful shutdown. I.e., the box/
node which is using the link under graceful shutdown as an Egress link for
the affected flows. 

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