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

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

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