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