Skip to content

Conversation

@job
Copy link

@job job commented Feb 9, 2026

BCP 214, section 3.1.1, suggests using the well-known GRACEFUL_SHUTDOWN BGP community (RFC8326) to facilitate smooth drainage of traffic prior to BGP session tear down. The goal is to reduce or avoid packet loss for outbound and inbound traffic flows initially forwarded along the peering link planned to be shut down.

With this routing policy change, Route Servers will preemptively converge onto alternative paths (provided those exist), or just continue to use the marked path until it is withdrawn. In other words, this implements a form of "make before break".

Even when no alternative paths exist in the Route Server's Loc-RIB itself, it is beneficial to promote the use of this BGP community, because its presence allows the RS peers (which hopefully do have alternative paths!) to preemptively converge.

This video explains the topic and benefits in more detail: https://www.youtube.com/watch?v=HGGRsJ-gjI4

BCP 214, section 3.1.1, suggests using the well-known GRACEFUL_SHUTDOWN
BGP community [RFC8326] to facilitate smooth drainage of traffic prior
to BGP session tear down. The goal is to reduce or avoid packet loss for
outbound and inbound traffic flows initially forwarded along the peering
link planned to be shut down.

With this routing policy change, Route Servers will preemptively converge
onto alternative paths (provided those exist), or just continue to use the
marked path until it is withdrawn. In other words, this implements a form
of "make before break".

Even when no alternative paths exist in the Route Server's Loc-RIB itself,
it is beneficial to promote the use of this BGP community, because its
presence allows the RS peers (which hopefully /do/ have alternative paths!)
to preemptively converge.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant