Re: Starting a discussion on graceful shutdown

[ibryskin@movaz.com]

Adrian,

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

Igor

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

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)

>
> 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?
IB>> The answer is Yes. The main (if not only) purpose of TE
advertisements is to influence on PCE, isn?t it ?

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

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.

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

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
> be taken out of
> service?
>

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.

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