Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Mon, 8 Aug 2005 16:09:29 +0200

> > Basically GR restart is:
> > 	Forwarding plane stays up / control plane says I'll be back.
> 
> Right. Though note that GR specifies a forwarding-state bit, 
> so you can signal to your peer, /after/ the fact (when you 
> bring your session back up), whether or not your forwarding 
> plane stayed up.

If you *know* the forwarding plane will be shutdown, will not
advertising this /before/ the failure?
 
> > Planned maintenance requirement is:
> 
> > 	Forwarding going away, control plane going away / let's do it
> >	gracefully.
> 
> Ok, I guess my question then is what you think can be done 
> for this case, eg /lack/ of graceful-restart capability.

You could:
-1- warn your peers about the planned maintenance
-2- keeps FIB & forwarding while BGP convergence
-3- shut the BGP session as usual.

> Further, as above, how can you even reliably distinguish 
> between the two cases above (presuming GR is enabled)?

This is a maintenance situation and the operator knows that the
forwarding plane needs to be shutdown.

> Given 
> the GR draft, you can't determine anything until the peer 
> comes back. Ie, given GR, there is a window of uncertainty 
> where you can not say whether forwarding stayed up or not, 
> you only know when it comes back and you can examine the F 
> bit in the GR capability advertisement for the appropriate AFI/SAFI.
> 
> Something to consider anyway (the interaction of the two).
> 
> A final thought: Does the second case even require any protocol work?

We hope that a least a significant part of the requirements could be
fullfilled without protocol extension.
 
> It strikes me that the second case can easily be handled 
> entirely within the confines of existing specified BGP, by 
> simply having an implementation take the relevant BGP 
> session(s) down (ie sending a
> CEASE) and just waiting a while to let the relevant remote 
> peers update their routes, before proceeding with actually 
> removing the routes from RIB and FIB and then restarting.

It could work in some situation but if your peers doesn't know about the
back up path (because of a RR on the path) you will lose traffic.
 
> I reckon the most protocol work this needs is just to have 
> implementations advertise a "I reckon I need X milliseconds 
> to clear Y number of routes" or even just "Hey, if you're 
> going down, try give me X seconds advance notice if you can" 
> capability, which could be used to supercede any 
> implementation specific default.
> 
> > Best regards,
> >
> > Nicolas Dubois
> > Tel :  0144442817
> 
> regards,
> -- 
> Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
> Fortune:
> Finagle's Seventh Law:
>  	The perversity of the universe tends toward a maximum.
> 

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Paul Jakma <[email-masked]>
Date: Mon, 8 Aug 2005 15:45:19 +0100 (IST)

> advertising this /before/ the failure?

I'm not terribly familiar with GR - I dont know. I don't /see/ how GR 
allows signalling intent of forwarding state in advance of the 
shutdown, but I could be wrong. You should ask the GR author.

At a guess, there's very little to be gained (in the context of GR 
solely). Signalling a fact (I /did/ keep my forwarding state up) is 
probably better than an intent (I /intend/ to keep my forwarding 
state up).

However, in the context of both GR and a "notify + wait a while" 
optimisation, it might indeed be an idea to consider this, and 
possibly modify GR. Ie to be able to signal intent to take down 
forwarding (an intention easier to satisfy than keeping forwarding 
up).

/Maybe/ this could be satisfied with additional NOTIFY CEASE 
sub-codes? Eg, ADMIN_RESTART (complete restart) and ADMIN_RESTART_BGP 
(restarting only BGP, intend to leave FIB in place). Seems hacky to 
use subcodes for anything other than informational purposes, but 
that's only way really.

> -3- shut the BGP session as usual.

Yep.

> fullfilled without protocol extension.

That seems likely.

So the main issue, it seems, is that interaction with GR needs to be 
considered. Which may require interacting additionally with the 
draft-ietf-idr-cease-subcode authors.

> It could work in some situation but if your peers doesn't know 
> about the back up path (because of a RR on the path) you will lose 
> traffic.

That would seem to be a route-reflector issue, best addressed 
seperately?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
The generation of random numbers is too important to be left to chance.