Subject: Starting a discussion on graceful shutdown

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Dec 2004 15:38:55 -0000

Hi,

http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-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?

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?

How should we consider the case of a node (data plane and/or control plane) being taken
out of service? Is a node simply a collection of links?

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

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?

Adrian

---

From: JP Vasseur <[email-masked]>
Date: Tue, 7 Dec 2004 19:32:50 -0500

Hi Adrian,

> offer upstream LSRs (in particular the ingress) the opportunity to use  

This is indeed the goal. Note that this is just one out of many other  
cases for which a graceful shutdown solution is desirable, the action  
(reroute of existing LSPs, avoidance of the network element for *new*  
LSPs, reoptimization, ...) may of course vary depending on the event.

> In order to achieve this, we need to communicate to the upstream nodes.

Right. Note that this might either be the impacted head-end LSRs *or*  
directly upstream neighbors *or* both depending on the requesting  
actions.

>  Should we choose

Both have pros and cons and are needed ... Routing is, in many cases,  
more efficient in term of sig overhead *but* limited to single area ...  
thus signaling is also required. The use of one of the other should IMO  
be specific of the graceful shutdown triggers and expected actions.

> computations from selecting the link that will be taken out of service?

Again this highly depends on the root cause ... Consider:
1) Link to be shutdown: all LSP (old and new) should be rerouted
2) Memory shortage on some equipment: only *new* LSP should avoid the  
equipment in question
3)  ....

> out of service? Is a node simply a collection of links?

Good question ... depends again on the data/control plane issue.

> link out of service, how does it inform the upstream node?

This should I think be configurable with the possible to offer a  
notification mechanism.

> section of any draft. Would the authors of  
> draft-ali-ccamp-mpls-graceful-shutdown-00.txt

Sure, we will be happy to write such a section.

Cheers.

JP.

---

From: [email-masked]
Date: Wed, 8 Dec 2004 09:32:12 -0500 (EST)

Adrian,

Thanks for starting these discussions. See my comments in-line.

Igor

> signaling or routing? Are there benefits that mean we should use both, or
Ø	to just one?

IB>> We need both: (a) routing for making sure that the link will not be
used for new LSPs; (b) signaling for suggesting mb4b on active LSPs going
through the link. However, I believe we have more that enough tools to
accomplish this. By re-advertising TE LINK TLV we achieve (a), by
inserting ALARM-SPEC into Resv and/or signaling PathErr with removal state
flag cleared we achieve (b)

> computations from selecting the link that will be taken out of service?
IB>> The answer is Yes. The main (if not only) purpose of TE
advertisements is to influence on PCE, isn’t it ?

> out of service? Is a node simply a collection of links?

IB>> From the PCE viewpoint a node is a vertex on TE network graph, while
links are edges/arcs. Hence node is not a collection of links, rather an
interconnection of local sides of its links. The removing of TE RTR TLV
advertisement de-synchronizes all links originating/terminating on the
node, making them unavailable for the path computation. It is also
possible to instruct active LSP ingresses to avoid using a node with
particular node ID (TE Router Address), rather than bunch of links, in
mb4b operations.

> need to be communicated more widely? If the downstream node decides to
Ø	link out of service, how does it inform the upstream node?

IB>> A node that decides to take a component out of service should
re-advertise TE LINK TLV associated with the local side of the
corresponding bundle.
I don’t think we have a solution how to swing an LSP from one component to
another if the current one is intended to go out of service. I always felt
that we are missing a mechanism to negotiate components between adjacent
nodes similar to the label negotiation.

> Does it matter whether it is the control plane or the data plane that will

IB>> It does for active LSPs. For instance, it is possible to temporarily
take out of service control plane of some node without performing mb4b
operations on LSPs going through the node.