[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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)
o) the document makes use of a link attribute (but where is this attribute defined ?)
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) 

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-shutdo
wn-02.txt
<http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutd
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-shutdo
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