Re: Summary [was: RE: Starting a discussion on graceful shutdown]

["Adrian Farrel" <adrian@olddog.co.uk>]

Thanks, Zafar.

Comments in line.

Adrian

> > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace
> > ful-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?
>
> Yes, we need both.

Well, I was kind of hoping for a reasoned debate :-)

> > 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?
>
> Yes,
>
> > How should we consider the case of a node (data plane and/or
> > control plane) being taken out of service?
>
> Yes,
>
> >Is a node simply a  collection of links?
>
> Yes, during graceful shutdown period.

So does that mean you would like to advertise the withdrawal of 10,000
links, or the withdrawal of one node. Recall that all link advertisement
is associated with the node, so node withdrawal is meaningful.

> > 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?
>
> Let head end do the mb4b,

Presumably this would not be true if the bundle was advertised as having
some form of link protection (and the ocmponent links provided this
protection).

> > If the downstream node decides to
> > take the component link out of service, how does it inform
> > the upstream node?

You missed this one.

> > Does it matter whether it is the control plane or the data
> > plane that will be taken out of service?
>
> Yes, if data plane is going OOS, we are loosing traffic and motivation
> behind mb4b to reduce traffic hit is lost.

Let me rephrase the question.
If I know that the control plane is going OOS and I want to continue to be
able to manage my LSPs I will want to move them to LSRs that will continue
to have an active control plane. The data plane through the impacted LSRs
may continue to be active (and therefore could continue to carry traffic).

Is this an important case? If so, do we manage it in the same way?

> > 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?
>
> Sure, we plan to revised the ID based on this survey as well as comments
> from the WG for the upcoming IETF.
>
> Thanks again Adrian for your suggestion and putting this together.
>
> Thanks
>
> Regards... Zafar
>
> >
> > Adrian
> >
> >
>
>