The Dynamic Negotiation of BGP Capabilities blog post generated almost no comments, apart from the #facepalm realization that a certain network operating system resets IBGP sessions when the sole EBGP session goes down, but there were a few interesting comments on LinkedIn and Twitter.

While most engineers easily relate to the awkwardness of bringing down a BGP session to enable new functionality (Tearing down BGP session, as a solution reminds me rebooting a host, as a solution.), it’s not as easy as it looks. As Adam Chappell put it “Dynamic capability renegotiation does tend to sound a bit like changing the tyres while still moving. Very neat if you can pull it off but so much to go wrong…”

Jeff Tantsura succinctly summarized the tradeoffs as “noone wants bugs in BGP”:

As per RFC5492, dealing with capabilities negotiation is pretty straightforward and done once in the session lifetime. Making it dynamic creates quite some complexity (think amount of code, error handling, etc).

On another side - how often do we introduce new BGP capabilities without code upgrade/not in maintenance windows/unplanned? The trade-off is really - complexity(and potential bugs(and noone wants bugs in BGP) ;-)) vs ability to introduce new functionality in a non disruptive way.

Dr. Tony Przygienda was even more succint:

Let’s put it that way, some things are easy to renogotiate, some will be very painful & some you probably shouldn’t even […try…] ;-) since you probably run multiple sessions to do it.

A few examples I could easily think of:

• Negotiating address families on demand should be a no-brainer. Adding an address family cannot hurt you (you can always reject the idea), and dropping an address family is equivalent to reseting the BGP session.
• Turning BGP Additional Paths on without clearing the BGP table first would be interesting. What Path ID do you assign to the entries already in the receiver’s RIB? Do you resend the same paths, but with Path ID? When can the receiver clean up the old paths?

Adam Chappell pointed out that (as is often the case) good design helps. For example, you could deploy a separate set of route reflectors per address family – adding an address family on a PE router would never tear down an existing BGP session.

If your network is not big enough to justify a pair of devices per address family, you might want to cheat with per-address-family loopback interfaces. Doing that is a bit tricky¹ as you have to establish BGP sessions between distinct pairs of IP addresses². More about that in another blog post;here’s the lab setup in case you want to try it out yourself – you’ll need netlab to set it up.

Your life becomes much easier if your vendor implemented Multisession BGP draft, another interesting idea that has been stuck in draft limbo for almost a decade for no apparent reason. Topic for yet another blog post.

Revision History

2021-12-20

You can run multiple sessions between a pair of BGP routers as long as they are using distinct endpoints on both ends.