Application of the Border Gateway Protocol in the Internet
obsoleted by
- rfc-1772 — Application of the Border Gateway Protocol in the Internet
obsoletes
- rfc-1268 — Application of the Border Gateway Protocol in the Internet
Extracted elements (23)
A border gateway should not advertise a route to exterior network X via another border gateway B until all interior gateways within the AS are ready to route traffic to X via the correct exit gateway B. Interior routing should converge on the proper exit gateway before advertising routes via that exit gateway to other AS's, to avoid black holes.
AS's are classified as stub (single connection, local traffic only), multihomed (multiple connections, refuses transit), or transit (multiple connections, carries transit traffic). A major goal of BGP usage is to control the flow of transit traffic.
Because a full AS path provides an efficient way to suppress routing loops and eliminates the count-to-infinity problem associated with distance vector algorithms, BGP imposes no topological restrictions on the interconnection of AS's.
BGP-4 extends BGP-3 specifically to support routing information aggregation and reduction based on CIDR, addressing Internet scaling problems: exhaustion of class-B address space, unmanageable routing table growth, and eventual 32-bit address exhaustion.
Path selection criteria include AS count (fewer is better), policy considerations, presence/absence of specific AS's, path origin (BGP-learned is better than EGP-learned), AS path subsets (shorter subsets preferred), and link dynamics (stable paths preferred over unstable). Link dynamics criteria must be used carefully to avoid routing instability.
Routing policies are not directly encoded in BGP; they are provided via configuration information. BGP enforces policies by affecting path selection from alternatives and controlling redistribution of routing information based on political, security, or economic considerations.
When all routers in an AS are BGP speakers (pervasive BGP), no BGP-IGP interaction is needed. The IGP is used only for intra-AS routing, and because all routers already have full BGP route information, routes may be advertised without waiting for IGP convergence.
When using BGP over Switched Virtual Circuits (SVCs), periodic KEEPALIVE messages may be undesirable because they keep SVCs permanently open. BGP supports SVC operation by allowing zero Hold Time in the OPEN message, eliminating periodic KEEPALIVEs and relying on the circuit manager and TCP instead.
When injecting BGP-4 routes carrying AS_SET path segments into BGP-3, the AS_PATH shall be constructed by treating AS_SET segments as AS_SEQUENCE segments, resulting in a single AS_SEQUENCE. This loses set/sequence information but does not affect routing loop suppression; it may affect policies based on AS_PATH content or ordering.
Within a single autonomous system, BGP conversations between all BGP speakers of that AS must be either all BGP-3 or all BGP-4, but not a mixture.
A conformant BGP-4 implementation is required to support all of the following options when injecting BGP-4 received routing information into BGP-3: inject default only (0.0.0.0), allow controlled deaggregation of specific routes, or allow export of only non-aggregated NLRI.
A route carrying the ATOMIC_AGGREGATE path attribute shall not be exported into either BGP-3 or EGP2 unless such exportation can be accomplished without exploding the NLRI of the route.
BGP implementations should allow an AS to assign an administrative degree of preference to a route based on the IP address of the neighbor it was received from. The allowed range of the assigned preference shall be between 0 and 2^31 - 1.
BGP implementations should allow an AS to control announcements of BGP-learned routes to adjacent AS's with at least per-network and per-AS granularity. When a new selected route cannot be announced to a particular peer, the local system must explicitly withdraw the previously announced route.
BGP implementations should allow an AS to ignore routes containing certain AS's in the AS_PATH attribute, implemented by assigning 'infinity' as the weight for such AS's; route selection must ignore routes with weight equal to infinity.
By default a BGP speaker should aggregate NLRI representing subnets to the corresponding network. Injecting NLRI representing arbitrary subnets into BGP without aggregation shall be controlled via configuration parameters.
For External BGP, BGP neighbors must belong to different AS's and share a common network, which should be used to carry BGP messages. Using BGP across an intervening AS invalidates the AS path information.
For SVC operation, the circuit manager must be able to determine link-layer unreachability within a predictable finite period, start a configurable dead timer on detecting unreachability, attempt to re-establish the link layer, and send a DEAD indication to TCP if the dead timer expires.
For SVC operation with a separate BGP process and circuit manager, a periodic two-way poll must be implemented. If the BGP process finds the circuit manager gone, it should close relevant TCP connections; if the circuit manager finds BGP gone, it should close all associated connections and reject further incoming connections.
Fundamental to BGP is the rule that an AS advertises to neighboring AS's only those routes that it uses, reflecting the hop-by-hop routing paradigm of the Internet.
Tagged IGP Rule 1: Information received via iBGP declaring a network unreachable must immediately be propagated to all External BGP neighbors. Tagged IGP Rule 2: Information about a reachable network X received via iBGP cannot be propagated to any eBGP neighbor unless the border gateway has an IGP route to X with identical BGP and IGP tags.
BGP communications with neighbors in different AS's are External BGP (eBGP); communications with neighbors in the same AS are Internal BGP (iBGP). All BGP speakers representing the same AS must give a consistent routing image to the outside.
Security issues are not discussed in this memo.