<div dir="ltr"><div>Hi Vincent,</div><div><br></div><div dir="ltr">On Thu, Oct 17, 2019 at 1:05 PM Vincent Bernat <<a href="mailto:bernat@luffy.cx">bernat@luffy.cx</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> ❦ 17 octobre 2019 11:29 +01, Neil Jerram <<a href="mailto:neil@tigera.io" target="_blank">neil@tigera.io</a>>:<br>
<br>
> In my setup, an instance of BIRD runs all the time, except for when it<br>
> needs to be restarted for a software update.<br>
><br>
> For that update scenario, I'd like BGP graceful restart to apply, so that<br>
> the stop-update-restart process does not cause the routes advertised by<br>
> this BIRD to be withdrawn from the rest of the BGP network.<br>
><br>
> For all other scenarios, however, I don't want any graceful restart.<br>
> Specifically, if there's a break in connectivity to a BGP peer, I want to<br>
> detect that as quickly as possible (with BFD), locally to remove the routes<br>
> learned from that peer, and for that peer to remove routes learned from me,<br>
> all immediately.<br>
><br>
> Is there some combination of configuration and procedure that can provide<br>
> both of those desires?<br>
<br>
You should look at the long lived graceful restart alternative. It will<br>
enable you to do software upgrades without impact without keeping routes<br>
around when a BGP session is cut unexpectedly, as long as you have<br>
alternative routes available.<br></blockquote><div><br></div><div>I have indeed been looking at LLGR, and I'm very grateful for your blog about it.</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>Best wishes,</div><div>   Neil</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div>