RE: Need to close on signaling solution for graceful shutdown (Follow-up on our Action Item)

["Zafar Ali \(zali\)" <zali@cisco.com>]

Hi Dimitri, 

There is a difference between expected operations in graceful restart
and graceful shutdown; hence my previous email. The draft already lists
Max Metric as a possible solution with motivation for selecting link
attribute based solution. If the WG agrees that use of Max Metric
suffices, we can fall back to the use of the Max Metric/ zero bw. We
will be posting an updated version later tonight. 

Thanks

Regards... Zafar  

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be 
> [mailto:Dimitri.Papadimitriou@alcatel.be] 
> Sent: Friday, March 03, 2006 6:46 PM
> To: Zafar Ali (zali)
> Cc: Adrian Farrel; Anca Zamfir (ancaz); ccamp@ops.ietf.org; 
> dpapadimitriou@psg.com; Jean Philippe Vasseur (jvasseur); 
> Kireeti Kompella; owner-ccamp@ops.ietf.org
> Subject: RE: Need to close on signaling solution for graceful 
> shutdown (Follow-up on our Action Item)
> 
> hi zafar
> 
> then i will express my concern in the other way around 
> concerning the "routing" part of this document: we have clean 
> procedures for planned node restart in RFC4203; hence, the 
> reason for having a "cleaner" procedure is totally unclear to 
> me both in terms of motivation and applicability
> 
> much thanks,
> - dimitri.
> 
> 
> 
> 
> 
> 
> 
> 
> "Zafar Ali \(zali\)" <zali@cisco.com>
> Sent by: owner-ccamp@ops.ietf.org
> 02/03/2006 07:06
>  
>         To:     <dpapadimitriou@psg.com>, Dimitri 
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <ccamp@ops.ietf.org>, "Adrian Farrel" 
> <adrian@olddog.co.uk>, "Anca Zamfir \(ancaz\)" 
> <ancaz@cisco.com>, "Jean Philippe Vasseur \(jvasseur\)" 
> <jvasseur@cisco.com>, "Kireeti Kompella" 
> <kireeti@juniper.net>
>         Subject:        RE: Need to close on signaling solution for 
> graceful shutdown (Follow-up on our Action Item)
> 
> 
> Hi Dimitri, 
> 
> Sorry for the delay in replying. Please see reply in-line. 
> 
> All, 
> 
> I am assuming the WG is ok with the signaling part of the solution. If
> you have any comments, please reply to my original email. We plan to
> refresh the ID before the flood gate closes. 
> 
> Thanks
> 
> Regards... Zafar 
> 
> > -----Original Message-----
> > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] 
> > Sent: Monday, February 20, 2006 2:01 AM
> > To: Zafar Ali (zali)
> > Cc: ccamp@ops.ietf.org; Adrian Farrel; Anca Zamfir (ancaz); 
> > Jean Philippe Vasseur (jvasseur); Kireeti Kompella
> > Subject: Re: Need to close on signaling solution for graceful 
> > shutdown (Follow-up on our Action Item)
> > 
> > 
> > zafar - thanks for the summary ... but i don't understand the 
> > following sentence
> > 
> > "The IGP based solution is also based on an existing framework."
> > 
> > to which framework are you referring to ?
> > 
> > i am more concerned with section 4.2, for three reasons
> > 
> > o) the document seems to say that such links could be used as 
> > last resort link for zero bandwidth LSP - note that this 
> > applies only to PSC links because non-PSC would not make use 
> > of such links - let's assume this may be the case, as you are 
> > dealing with a "planned outage" i am not sure you are going 
> > to make a lot of operations such as new path computations 
> > during such event (and risk further degradation)
> > 
> 
> A link may end-up with max metric for multiple reasons and without the
> link attribute there is no way a node can tell what the 
> reason is, e.g.
> a restarting node may advertises the max matrices. Furthermore, if the
> resource under graceful deletion is the last resort then the node
> hosting the graceful deletion resource will not receive new signaling
> messages. Also, graceful deletion is not the main motivation for the
> introduction of the link attribute sub-TLV; we are just 
> overloading the
> use of link attribute to provide a cleaner specification. Hence, I
> mention "existing framework". We can enhance the text in the ID to be
> more specific in this notification. 
> 
> > o) the document makes use of a link attribute (but where is 
> > this attribute defined ?)
> > 
> 
> The link attribute ID-es needs to be refreshed. 
> 
> > o) this section forces to have to have two different 
> > procedures (as planned restarting nodes advertise their link 
> > with these attributes making them unusable before the restart 
> > occurs, section 2 of RFC4203)
> > 
> 
> See my comment above. 
> 
> > thanks,
> > - dimitri.
> > 
> > 
> > Zafar Ali (zali) wrote:
> > 
> > > Dear Ccampers:
> > > 
> > > 
> > > 
> > > This is a follow-up on our action item from the last IETF 
> > meeting to 
> > > send an email to close the signaling solution for 
> graceful shutdown 
> > > procedure proposed in 
> > > 
> > 
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut
> > > do
> > > wn-02.txt
> > > 
> > 
> <http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shu
> > > td
> > > own-02.txt> . 
> > > 
> > > 
> > > 
> > > During the meeting it was clear that we have an agreement on the 
> > > requirement front. We also have an agreement that we need 
> > both routing 
> > > and signaling based solutions. This is because an IGP only based 
> > > solution is not applicable when dealing with Inter-area and 
> > Inter-AS 
> > > traffic engineering, as LSA or LSP flooding is restricted to IGP 
> > > areas/levels. Consequently, RSVP based mechanisms are 
> > required to cope 
> > > with TE LSPs spanning multiple domains. The draft presents 
> > > complementary mechanisms for RSVP-TE and IGP for Graceful 
> Shutdown. 
> > > The IGP based solution is also based on an existing 
> framework. Our 
> > > action item is to close on the signaling based counterpart.
> > > 
> > > 
> > > 
> > > Before we compare the candidate solution, let's discuss and 
> > agree on 
> > > general requirement for a signaling based graceful shutdown 
> > mechanism.
> > > In graceful shutdown procedure, as the Ingress LSR is expected to 
> > > perform make-before-break for the LSP (using the resource that is 
> > > being shutdown), we should be able to specify the TE 
> > resource (link/ 
> > > node) under graceful shutdown.  Furthermore, conveying signaling 
> > > message to the Ingress LSR suffices. I.e., we can make use 
> > of the Notify Message.
> > > 
> > > 
> > > 
> > > One of the solutions proposed during these discussions is 
> > to make use 
> > > of the admin status object. However, admin status cannot contain 
> > > information about TE resource under Graceful Shutdown. 
> > Hence, we did 
> > > not consider use of admin status object as a possible solution.
> > > 
> > > 
> > > 
> > > Another alternate that was put forward is the use ALARM_ 
> > SPEC Objects.
> > > While ALARM_ SPEC Objects has ability to Signal Info about 
> > TE resource 
> > > under Graceful shutdown, use of this object in the notify 
> > message is 
> > > not defined. We also feel use of the ALARM_ SPEC Objects is 
> > heavy duty 
> > > for signaling simple Graceful Shutdown condition.
> > > 
> > > 
> > > 
> > > We propose to overload "TE link maintenance required" 
> > sub-code of the 
> > > Notify Error Code (24) of the ERROR_SPEC. We believe this is the 
> > > simplest solution with existing/ well used way to signal 
> > information 
> > > about TE resource under Graceful Shutdown. Furthermore, the 
> > ERROR_SPEC 
> > > with code 24/ sub-code TBD can then be carried in either 
> PathErr or 
> > > Notify message to signal graceful condition.
> > > 
> > > 
> > > 
> > > Can you please send your comments to this by the end of 
> > this week so 
> > > we can update the ID, if needed?
> > > 
> > > 
> > > 
> > > Thanks
> > > 
> > > 
> > > 
> > > Regards... Zafar
> > > 
> > > This is a follow-up on our action item from the last IETF 
> > meeting to 
> > > send an email to close the signaling solution for 
> graceful shutdown 
> > > procedure proposed in 
> > > 
> > 
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shut
> > > do
> > > wn-02.txt. 
> > > 
> > > 
> > > 
> > > During the meeting it was clear that we have an agreement on the 
> > > requirement front. We also have an agreement that we need 
> > both routing 
> > > and signaling based solutions. This is because an IGP only based 
> > > solution is not applicable when dealing with Inter-area and 
> > Inter-AS 
> > > traffic engineering, as LSA or LSP flooding is restricted to IGP 
> > > areas/levels. Consequently, RSVP based mechanisms are 
> > required to cope 
> > > with TE LSPs spanning multiple domains. The draft presents 
> > > complementary mechanisms for RSVP-TE and IGP for Graceful 
> Shutdown. 
> > > The IGP based solution is also based on an existing 
> framework. Our 
> > > action item is to close on the signaling based counterpart.
> > > 
> > > 
> > > 
> > > Before we compare the candidate solution, let's discuss and 
> > agree on 
> > > general requirement for a signaling based graceful shutdown 
> > mechanism.
> > > In graceful shutdown procedure, as the Ingress LSR is expected to 
> > > perform make-before-break for the LSP (using the resource that is 
> > > being shutdown), we should be able to specify the TE 
> > resource (link/ 
> > > node) under graceful shutdown.  Furthermore, conveying signaling 
> > > message to the Ingress LSR suffices. I.e., we can make use 
> > of the Notify Message.
> > > 
> > > 
> > > 
> > > One of the solutions proposed during these discussions is 
> > to make use 
> > > of the admin status object. However, admin status cannot contain 
> > > information about TE resource under Graceful Shutdown. 
> > Hence, we did 
> > > not consider use of admin status object as a possible solution.
> > > 
> > > 
> > > 
> > > Another alternate that was put forward is the use ALARM_ 
> > SPEC Objects.
> > > While ALARM_ SPEC Objects has ability to Signal Info about 
> > TE resource 
> > > under Graceful shutdown, use of this object in the notify 
> > message is 
> > > not defined. We also feel use of the ALARM_ SPEC Objects is 
> > heavy duty 
> > > for signaling simple Graceful Shutdown condition.
> > > 
> > > 
> > > 
> > > We propose to overload "TE link maintenance required" 
> > sub-code of the 
> > > Notify Error Code (24) of the ERROR_SPEC. We believe this is the 
> > > simplest solution with existing/ well used way to signal 
> > information 
> > > about TE resource under Graceful Shutdown. Furthermore, the 
> > ERROR_SPEC 
> > > with code 24/ sub-code TBD can then be carried in either 
> PathErr or 
> > > Notify message to signal graceful condition.
> > > 
> > > 
> > > 
> > > Can you please send your comments to this by the end of 
> > this week so 
> > > we can update the ID, if needed?
> > > 
> > > 
> > > 
> > > Thanks
> > > 
> > > 
> > > 
> > > Regards... Zafar
> > > 
> > > 
> > > 
> > > 
> > 
> 
>