Avoid BGP Best Path Transitions from One External to Another
RFC 5004
|
| Document |
Type |
|
RFC - Proposed Standard
(September 2007; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5004 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Bill Fenner
|
|
Send notices to |
|
(None)
|
Network Working Group E. Chen
Request for Comments: 5004 S. Sangli
Category: Standards Track Cisco Systems
September 2007
Avoid BGP Best Path Transitions from One External to Another
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
In this document, we propose an extension to the BGP route selection
rules that would avoid unnecessary best path transitions between
external paths under certain conditions. The proposed extension
would help the overall network stability, and more importantly, would
eliminate certain BGP route oscillations in which more than one
external path from one BGP speaker contributes to the churn.
1. Introduction
The last two steps of the BGP route selection (Section 9.1.2.2,
[BGP]) involve comparing the BGP identifiers and the peering
addresses. The BGP identifier (treated either as an IP address or
just an integer [BGP-ID]) for a BGP speaker is allocated by the
Autonomous System (AS) to which the speaker belongs. As a result,
for a local BGP speaker, the BGP identifier of a route received from
an external peer is just a random number. When routes under
consideration are from external peers, the result from the last two
steps of the route selection is therefore "random" as far as the
local BGP speaker is concerned.
It is based on this observation that we propose an extension to the
BGP route selection rules that would avoid unnecessary best-path
transitions between external paths under certain conditions. The
proposed extension would help the overall network stability, and more
importantly, would eliminate certain BGP route oscillations in which
more than one external path from one BGP speaker contributes to the
churn.
Chen & Sangli Standards Track [Page 1]
RFC 5004 Best BGP Route Selection September 2007
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. The Algorithm
Consider the case in which the existing best path A is from an
external peer, and another external path B is then selected as the
new best path by the route selection algorithm described in [BGP].
When comparing all the paths in route selection, if neither Path A
nor Path B is eliminated by the route selection algorithm prior to
Step f) -- BGP identifier comparison (Section 9.1.2.2, [BGP]) -- we
propose that the existing best path (Path A) be kept as the best path
(thus avoiding switching the best path to Path B).
This algorithm SHOULD NOT be applied when either path is from a BGP
Confederation peer.
In addition, the algorithm SHOULD NOT be applied when both paths are
from peers with an identical BGP identifier (i.e., there exist
parallel BGP sessions between two BGP speakers). As the peering
addresses for the parallel sessions are typically allocated by one AS
(possibly with route selection considerations), the algorithm (if
applied) could impact the existing routing setup. Furthermore, by
not applying the algorithm, the allocation of peering addresses would
remain as a simple and effective tool in influencing route selection
when parallel BGP sessions exist.
4. The Benefits
The proposed extension to the BGP route selection rules avoids
unnecessary best-path transitions between external paths under
certain conditions. Clearly, the extension would help reduce routing
and forwarding changes in a network, thus helping the overall network
stability.
More importantly, as shown in the following example, the proposed
extension can be used to eliminate certain BGP route oscillations in
which more than one external path from one BGP speaker contributes to
the churn. Note however, that there are permanent BGP route
oscillation scenarios [RFC3345] that the mechanism described in this
document does not eliminate.
Chen & Sangli Standards Track [Page 2]
Show full document text