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

["Zafar Ali" <zali@cisco.com>]

Dear Adrian, 

Please see my reply in-line. 

Thanks again for your input.

Regards... Zafar

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> Sent: Thursday, February 17, 2005 4:01 PM
> To: Zafar Ali; ccamp@ops.ietf.org
> Subject: Re: Summary [was: RE: Starting a discussion on 
> graceful shutdown]
> 
> 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 :-)

The reason for me not listing the motivation as I was trying to summarize
the discussion on this thread. Here are the reasons/ requirements for having
complementary mechanism in IGP and RSVP-TE (as we discussed on the list).

- It is required to prevent other network nodes to use network resources
which are about to be shutdown, should new TE LSP be set up. As RSVP
mechanisms only convey the information for the transiting LSPs to the router
along the upstream Path and not to all nodes in the network, indication of
graceful shutdown via IGP flooding is required to discourage a node from
establishing new LSPs through the resources being shut-down.

- Graceful shutdown mechanisms are required to address TE LSPs spanning
multiple domains, as well as intra domain TE LSPs. Here, a domain is defined
as either an IGP area or an Autonomous System. An IGP 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.

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

Please see requirements listed above. 

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

I think removal of Router Address TLV would suffice. 

> 
> > > 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 
> component links provided this protection).

Yes, it is required to co-ordinate graceful shutdown with the protection
available for the TE link or the affected LSP. The draft did list the
following case, 

"When a graceful shutdown operation is performed along the path of a
protected LSP, the PLR MAY trigger Fast Reroute [FRR] for the appropriate
set of affected TE LSPs and forward a Path Error with "Tunnel locally
repaired" sub-code, as per the procedures specified in [MPLS-FRR]". 

When unbundled TE link is protected and maintenance of components within the
protected TE link is possible using means other than graceful shutdown
mechanisms (e.g., by L2), graceful shutdown may be handled by a local
switchover without informing the network of graceful shutdown condition.

In case of bundled TE links, RSVP flows are "pined" to a component link and
removal of that component link does affect the flows using it. Hence removal
of a component link has to be handled at the MPLS layer using means like
mb4b, FRR, path/ segment protection. 

In the case of Path/ segment protection, it is also possible to make use of
protection switchover mechanism (instead of mb4b) but IMO this is a matter
of local choice at the head-end LSR. The job of graceful shutdown mechanism
is to carry information about the graceful shutdown event and specify the
resource under graceful shutdown. 

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

At present draft mentions the use of perr with "Local component link
maintenance" flag and assumes a head-end based rerouting/ mb4b. 

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

I am not sure if I understood your comment completely. However, the ID
mentions about Grace Period and Removal of data plane associated with the
LSP under mb4b. 

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