rfc-7964

Solutions for BGP Persistent Route Oscillation

D. Walton, A. Retana, E. Chen, J. Scudder
date2016-09 streamIETF areartg wgidr statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc7964 doi10.17487/RFC7964
Routing information reduction by BGP Route Reflection or Confederation can result in persistent internal BGP route oscillations with certain routing setups and network topologies. This document specifies two sets of additional paths that can be used to eliminate these route oscillations in a network.

Extracted elements (19)

design-rationale §4

A route reflection cluster or confederation sub-AS should be designed so that IGP metrics for intra-cluster links are much smaller than for inter-cluster links. This practice ensures consistent routing within a cluster and is a prerequisite for Group Best Paths to be sufficient to eliminate MED-induced oscillations.

bgp, routing

design-rationale §A

Appendix A proves that Group Best Paths are adequate when the IGP metric constraint is followed: if no path in a cluster survives global comparisons, the Group Best Path comes from another cluster and its advertisement does not depend on paths received from that peer, breaking the oscillation cycle.

bgp, routing

design-rationale §6

The advertisement of multiple paths should be limited to prefixes affected by MED-induced route oscillation, since carrying additional paths impacts memory usage and routing convergence. Configuration workarounds should also be considered before deploying the multi-path advertisement mechanism.

bgp, routing

design-rationale §6

The Group Best Paths approach is bounded in the number of advertised paths by the number of neighbor-ASes for a particular address prefix, rather than the total number of paths. This is typically small due to the limited number of upstream providers and the nature of customer route advertisement at IXPs.

bgp, routing

design-rationale §1

The MULTI_EXIT_DISC (MED) attribute has played a pivotal role in virtually all known persistent IBGP route oscillations caused by Route Reflection or Confederation. The document uses the term 'MED-induced route oscillation' to refer specifically to these persistent oscillations where MED is a contributing factor.

bgp, routing

design-rationale §1

To eliminate MED-induced route oscillations, a route reflector or confederation ASBR needs to advertise more than just the best path for a prefix. Two approaches are identified: advertising all available paths (equivalent to full IBGP mesh) or advertising only the Group Best Paths per neighbor-AS, which is sufficient under common topological constraints.

bgp, routing

interoperability-note §1

Both the Available Paths and Group Best Paths approaches are implemented using the ADD-PATH mechanism defined in RFC 7911. No other assumptions in functionality beyond the base BGP specification (RFC 4271) are required.

bgp, routing

interoperability-note §6

The Group Best Paths approach may still be inadequate for certain networks where other routing inconsistencies such as forwarding loops exist, or where the required topological constraints are operationally challenging. In such cases, advertising Available Paths may be used as a fallback.

bgp, routing

normative-requirement §5.1 MAY

A route reflector MAY also advertise to a route reflection client the Group Best Paths (or Available Paths) received from its other clients.

bgp, routing

normative-requirement §5.2 MUST

For a particular <AFI, SAFI>, a confederation ASBR MUST include that <AFI, SAFI> with the 'Send/Receive' field set to 2 or 3 in the ADD-PATH Capability advertised to both IBGP peers and confederation-external peers.

bgp, routing

normative-requirement §5.1 MUST

For a particular <AFI, SAFI>, a route reflector MUST include that <AFI, SAFI> with the 'Send/Receive' field set to 2 (send multiple paths) or 3 (send/receive multiple paths) in the ADD-PATH Capability advertised to an IBGP peer.

bgp, routing

normative-requirement §5.1 MUST

If an IBGP peer is a non-client, the route reflector MUST advertise to the peer the Group Best Paths (or Available Paths) received from its clients.

bgp, routing

normative-requirement §5.1 MUST

If the ADD-PATH Capability is received from an IBGP peer with 'Send/Receive' set to 1 or 3 for the same <AFI, SAFI>, and the peer is a route reflection client, the route reflector MUST advertise to that client the Group Best Paths (or Available Paths) received from its non-client IBGP peers.

bgp, routing

normative-requirement §5.2 MUST

If the peer is confederation-external, the confederation ASBR MUST advertise to it the Group Best Paths (or Available Paths) received from its IBGP peers.

bgp, routing

normative-requirement §5.2 MUST

When the ADD-PATH Capability is received from an IBGP or confederation-external peer with 'Send/Receive' set to 1 or 3, if the peer is internal, the confederation ASBR MUST advertise to it the Group Best Paths (or Available Paths) received from its confederation-external peers.

bgp, routing

protocol-element §4

A 'Group Best Path' is the most preferred path within a group of routes sharing the same neighbor-AS. The MED is only comparable among routes with the same neighbor-AS, so route selection conceptually groups paths by neighbor-AS first, selects the Group Best Path per group, then selects the overall best path among those.

bgp, routing

protocol-element §3

'Available Paths' refers to the advertisement of all available paths for an address prefix by a route reflector or confederation ASBR. This approach yields the same routing information and consistency as a full IBGP mesh and eliminates MED-induced oscillations entirely.

bgp, routing

protocol-element §4

'neighbor-AS' for a route is the neighboring AS from which the route was received, calculated per Section 9.1.2.2 of RFC 4271 and Section 5.3 of RFC 5065. A Group Best Path for a prefix can be identified by the combination of address prefix and neighbor-AS, and neighbor-AS may be used as the path identifier in ADD-PATH.

bgp, routing

security-consideration §7

This extension to BGP does not change the underlying security issues inherent in the existing BGP protocol as specified in RFC 4271. No new security risks are introduced.

bgp, security, routing