BGP Wedgies
RFC 4264
|
| Document |
Type |
|
RFC - Informational
(November 2005; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4264 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
David Kessens
|
|
Send notices to |
|
dmm@1-4-5.net, isoc-contact@aarnet.edu.au, dmm@cisco.com, dmm@uoregon.edu
|
Network Working Group T. Griffin
Request for Comments: 4264 University of Cambridge
Category: Informational G. Huston
APNIC
November 2005
BGP Wedgies
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
It has commonly been assumed that the Border Gateway Protocol (BGP)
is a tool for distributing reachability information in a manner that
creates forwarding paths in a deterministic manner. In this memo we
will describe a class of BGP configurations for which there is more
than one potential outcome, and where forwarding states other than
the intended state are equally stable. Also, the stable state where
BGP converges may be selected by BGP in a non-deterministic manner.
These stable, but unintended, BGP states are termed here "BGP
Wedgies".
Table of Contents
1. Introduction ....................................................2
2. Describing BGP Routing Policy ...................................2
3. BGP Wedgies .....................................................3
4. Multi-Party BGP Wedgies .........................................6
5. BGP and Determinism .............................................7
6. Security Considerations .........................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
Griffin & Huston Informational [Page 1]
RFC 4264 BGP Wedgies November 2005
1. Introduction
It has commonly been assumed that the Border Gateway Protocol (BGP)
[RFC1771] is a tool for distributing reachability information in a
manner that creates forwarding paths in a deterministic manner. This
is a 'problem statement' memo that describes a class of BGP
configurations for which there is more than one stable forwarding
state. In this class of configurations there exist multiple stable
forwarding states. One of these stable forwarding states is the
intended state, with other stable forwarding states being unintended.
The BGP convergence process of selection of a stable forwarding state
may operate in a non-deterministic manner in such cases.
These stable, but unintended, BGP states are termed here "BGP
Wedgies".
2. Describing BGP Routing Policy
BGP routing policies generally reflect each network administrator's
objective to optimize their position with respect to their network's
cost, performance, and reliability.
With respect to cost optimization, the local network's default
routing policy often reflects a local preference to prefer routes
learned from a customer to routes learned from some form of peering
exchange. In the same vein, the local network is often configured to
prefer routes learned from a peer or a customer over those learned
from a directly connected upstream transit provider. These
preferences may be expressed via a local preference configuration
setting, where the local preference overrides the AS path length
metric of the base BGP operation.
In terms of engineering reliability in the inter-domain routing
environment it is commonly the case that a service provider may enter
into arrangements with two or more upstream transit providers,
passing routes to all upstream providers, and receiving traffic from
all sources. If the path to one upstream fails, the traffic will
switch to other links. Once the path is recovered, the traffic
should switch back.
In such situations of multiple upstream providers it is also common
to place a relative preference on the providers, so that one
connection is regarded as a preferred, or "primary" connection, and
other connections are regarded as less preferred, or "backup"
connections. The intent is typically that the backup connections
will be used for traffic only for the duration of a failure in the
primary connection.
Griffin & Huston Informational [Page 2]
RFC 4264 BGP Wedgies November 2005
Show full document text