BGP graceful restart for software update only?

[Neil Jerram]

Hi Vincent,

On Thu, Oct 17, 2019 at 1:05 PM Vincent Bernat <bernat at luffy.cx> wrote:

>  ❦ 17 octobre 2019 11:29 +01, Neil Jerram <neil at tigera.io>:
>
> > In my setup, an instance of BIRD runs all the time, except for when it
> > needs to be restarted for a software update.
> >
> > For that update scenario, I'd like BGP graceful restart to apply, so that
> > the stop-update-restart process does not cause the routes advertised by
> > this BIRD to be withdrawn from the rest of the BGP network.
> >
> > For all other scenarios, however, I don't want any graceful restart.
> > Specifically, if there's a break in connectivity to a BGP peer, I want to
> > detect that as quickly as possible (with BFD), locally to remove the
> routes
> > learned from that peer, and for that peer to remove routes learned from
> me,
> > all immediately.
> >
> > Is there some combination of configuration and procedure that can provide
> > both of those desires?
>
> You should look at the long lived graceful restart alternative. It will
> enable you to do software upgrades without impact without keeping routes
> around when a BGP session is cut unexpectedly, as long as you have
> alternative routes available.
>

I have indeed been looking at LLGR, and I'm very grateful for your blog
about it.

I'm not sure I'm persuaded by your argument, though, that LLGR is desirable
because BFD could generate a false negative.  Wouldn't it be better to
eliminate those false negatives by allowing BFD to run a more slowly and/or
with a larger multiplier?

IIUC, the benefit of GR, for a planned software update, is that it can
completely avoid any route flapping in the connected BGP peers - in terms
both of the data path and the BGP control plane.  With LLGR in that
scenario, I believe there will be BGP control plane traffic, and other
BIRDs updating their local kernel with least-preferred routes.  I suppose
it is still true that there is no data path flapping, but there *has* been
a lot of control plane churn, which traditional GR would have avoided.  Is
that understanding all correct?

Best wishes,
   Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20191017/60a7d404/attachment.htm>