Advertisement of Multiple Paths in BGP
Extracted elements (19)
Standard BGP (RFC 4271) allows only one path per address prefix; a new advertisement for the same NLRI implicitly replaces the previous one. ADD-PATH introduces a Path Identifier so multiple paths for the same prefix can coexist, reducing persistent route oscillations and enabling optimal routing and faster convergence via alternate/backup paths.
When a provider edge or peering router advertises multiple paths to internal neighbors and additional disambiguation is needed, attributes such as Edge_Discriminator (draft FAST) may be used; however, the use of such additional information is outside the scope of this document.
The only explicit indication that ADD-PATH extended NLRI encoding is in use is the exchange of Capabilities (Section 4). A packet analyzer lacking prior knowledge of the negotiated capabilities may not be able to correctly decode BGP UPDATE messages on an active ADD-PATH session.
A BGP speaker MUST assign the Path Identifier such that the (Prefix, Path Identifier) combination uniquely identifies a path advertised to a neighbor.
A BGP speaker SHOULD include the best route (per RFC 4271) when advertising more than one path to a neighbor, unless that path was received from that same neighbor.
A BGP speaker that re-advertises a route MUST generate its own Path Identifier to be associated with the re-advertised route.
A BGP speaker wishing to indicate support for multiple AFI/SAFIs MUST include all the information in a single instance of the ADD-PATH Capability.
A new advertisement for a given address prefix and Path Identifier replaces a previous advertisement for the same address prefix and Path Identifier. If a BGP speaker receives a withdrawal for a prefix with a Path Identifier not seen before, it SHOULD silently ignore it.
Because Path Identifiers are locally assigned and may not persist across a control plane restart, an implementation SHOULD take special care so that the forwarding plane of a Receiving Speaker (RFC 4724) is not affected during graceful restart of a BGP session.
If a Send/Receive field value other than 1, 2, or 3 is received, the ADD-PATH Capability SHOULD be treated as not understood and ignored per RFC 5492.
To send multiple paths to a peer, a BGP speaker MUST advertise the ADD-PATH Capability with Send/Receive set to 2 or 3, and MUST receive from its peer the ADD-PATH Capability with Send/Receive set to 1 or 3, for the corresponding <AFI, SAFI>.
When both peers have negotiated ADD-PATH capability for an <AFI, SAFI>, a BGP speaker MUST generate route updates based on the combination of address prefix and Path Identifier and use the extended NLRI encodings defined in this document.
A Path Identifier is a four-octet locally assigned value that, combined with the address prefix, uniquely identifies a path advertised to a neighbor. The assignment is a local matter, but the (Prefix, Path Identifier) tuple MUST uniquely identify each advertised path.
The ADD-PATH Capability has Capability Code 69 and a variable-length Capability Value consisting of one or more (AFI, SAFI, Send/Receive) tuples, each 4 octets total.
IANA assigned value 69 to the ADD-PATH Capability in the 'Capability Codes' registry.
Advertising multiple paths for a large number of prefixes may allow a BGP peer to cause memory exhaustion or network-wide instability on the receiving speaker, which can constitute a denial-of-service attack. The document notes this is not a new vulnerability but is present in the base BGP specification (RFC 4272).
The ADD-PATH Capability is intended for specific use cases such as eliminating MED-induced route oscillations. Users are encouraged to study best practices in draft-ietf-idr-add-paths-guidelines before deployment to understand behavioral impact.
Each ADD-PATH Capability tuple contains: Address Family Identifier (2 octets), Subsequent Address Family Identifier (1 octet), and Send/Receive (1 octet). Send/Receive values are: 1 = receive multiple paths, 2 = send multiple paths, 3 = both.
The NLRI encoding is extended by prepending a 4-octet Path Identifier field before the existing Length (1 octet) and Prefix (variable) fields. This extended encoding is used in UPDATE messages when ADD-PATH is negotiated.