Avoid BGP Best Path Transitions from One External to Another
Extracted elements (11)
The algorithm is backward-compatible and can be deployed on a per-BGP-speaker basis without introducing any backward compatibility issues, making immediate incremental deployment possible.
The BGP identifier of a route received from an external peer is effectively a random number from the local speaker's perspective, since identifiers are allocated by the remote AS. The last two tie-breaking steps of BGP route selection therefore produce arbitrary results for external-to-external comparisons, motivating the stability extension.
The parallel-session exclusion is intentional: peering addresses for parallel sessions are typically allocated by one AS with route selection in mind, so applying the stability algorithm could disrupt existing routing setup and should not override that deliberate configuration.
The proposed extension introduces some non-determinism in BGP route selection compared to existing behavior; however, this non-determinism can be fully eliminated by using existing mechanisms such as LOCAL_PREF or MED if deterministic selection is required.
There are permanent BGP route oscillation scenarios described in RFC 3345 that this mechanism does not eliminate; the algorithm only addresses oscillations caused by multiple external paths from one BGP speaker contributing to churn.
The algorithm SHOULD NOT be applied when both paths are from peers with an identical BGP identifier, i.e., when parallel BGP sessions exist between two BGP speakers, to preserve peering address allocation as a route selection tool.
The best-path stability algorithm SHOULD NOT be applied when either path is from a BGP Confederation peer.
When the existing best path A and a new candidate best path B are both from external peers and neither is eliminated prior to the BGP identifier comparison step (Step f), the existing best path A SHOULD be kept as the best path to avoid unnecessary transitions.
The algorithm targets the BGP route selection process defined in RFC 4271 Section 9.1.2.2, specifically the tie-breaking steps involving BGP identifier comparison (Step f) and peering address comparison, and proposes keeping the existing best external path when these steps would otherwise trigger a switch.
The route oscillation example involves route reflectors (R1 with client R3, R2 with client R4) where interaction between route reflection (RFC 4456) and MED causes churning; applying the algorithm at R3 prevents switching from path (a) to (b) after R1 withdraws (c), stopping the oscillation.
This extension does not introduce any security issues.