rfc-3065

Autonomous System Confederations for BGP

P. Traina, D. McPherson, J. Scudder
date2001-02 streamIETF areartg wgidr statusPROPOSED STANDARD pages11 canonicalhttps://www.rfc-editor.org/rfc/rfc3065 doi10.17487/RFC3065 errataview
This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. [STANDARDS-TRACK]

obsoleted by

obsoletes

Extracted elements (17)

design-rationale §4

BGP confederations were designed to avoid the O(n^2) full-mesh IBGP scaling problem by subdividing a large AS into Member-ASes while presenting the entire confederation as a single AS to external peers, thus hiding internal topology and avoiding AS_PATH inflation visible to the global Internet.

bgp, routing

design-rationale §Appendix A

The AS_CONFED_SEQUENCE and AS_CONFED_SET type values were reversed from RFC 1965 (swapping 3 and 4) because the initial widely-deployed implementations had them backwards from the original spec, and subsequent implementations followed suit; the values were changed to match deployed reality and foster interoperability.

bgp, routing

interoperability-note §8

Any BGP speaker not supporting the AS_CONFED_SET and AS_CONFED_SEQUENCE extensions will generate a NOTIFICATION message specifying an UPDATE Message Error with sub-code Malformed AS_PATH when it receives an UPDATE containing these segment types.

bgp, routing

interoperability-note §9

Confederations (like route reflectors) can cause permanent oscillation between candidate routes when using BGP tie-breaking rules, because different reachability information is excluded at different locations. Care must be taken in selecting MED values and tie-breaking policy.

bgp, routing

interoperability-note §9

Improper confederation configuration can cause routing information to be duplicated across member ASes, wasting resources, causing unnecessary route flaps, and delaying convergence. Manual filtering of duplicate advertisements may be required.

bgp, routing

normative-requirement §6 MUST

A BGP speaker receiving an AS_PATH containing an AS matching its own confederation, or an AS_CONFED_SEQUENCE/AS_CONFED_SET containing its own Member AS Number, SHALL treat the path as if it contained its own AS number (loop detection).

bgp, routing

normative-requirement §6 MUST

A confederation member MUST use its AS Confederation ID in all transactions with peers that are not members of its confederation, in OPEN messages and in the AS_PATH attribute.

bgp, routing

normative-requirement §8 MUST

All BGP speakers participating in a confederation MUST support BGP confederations (i.e., recognize AS_CONFED_SET and AS_CONFED_SEQUENCE segment types). BGP speakers outside the confederation need not support these extensions.

bgp, routing

normative-requirement §7 MUST

It SHALL be legal for a BGP speaker to advertise an unchanged NEXT_HOP and MED attribute to peers in a neighboring AS within the same confederation, and the restriction against sending LOCAL_PREFERENCE to intra-confederation peers is removed.

bgp, routing

normative-requirement §7 MUST

Path selection criteria for routes received from confederation members MUST follow the same rules used for routes received from members inside the same autonomous system, as specified in BGP-4.

bgp, routing

normative-requirement §6.1 MUST

The originating speaker SHALL include an empty AS_PATH attribute in UPDATE messages sent to BGP speakers in its own Member AS, include its Member AS Number in an AS_CONFED_SEQUENCE for intra-confederation neighbors, and include its confederation AS in an AS_SEQUENCE for external peers.

bgp, routing

normative-requirement §6.1 MUST NOT

When advertising a route to a BGP speaker in its own AS, the advertising speaker SHALL NOT modify the AS_PATH attribute.

bgp, routing

normative-requirement §6.1 MUST

When advertising to a BGP speaker in a neighboring Member-AS within the confederation, the speaker SHALL prepend its own AS number to an existing AS_CONFED_SEQUENCE, or prepend a new AS_CONFED_SEQUENCE segment if the first segment is not of that type.

bgp, routing

normative-requirement §6.1 MUST

When advertising to a BGP speaker outside the confederation, the advertising speaker SHALL strip all leading AS_CONFED_SEQUENCE and AS_CONFED_SET segments from the AS_PATH before prepending its own Confederation ID in an AS_SEQUENCE segment.

bgp, routing

protocol-element §3

An AS Confederation is a collection of autonomous systems advertised as a single AS number to BGP speakers external to the confederation. It has an AS Confederation Identifier (externally visible AS number) and contains Member-ASes with Member-AS Numbers visible only internally.

bgp, routing

security-consideration §10

This extension to BGP does not change the underlying security issues inherent in the existing BGP protocol; the security properties are the same as those defined for BGP-4 (RFC 2385 TCP MD5 signature option applies).

bgp, security, routing

wire-format §5

AS_CONFED_SEQUENCE (type 3) is an ordered set of Member AS Numbers in the local confederation that an UPDATE message has traversed. AS_CONFED_SET (type 4) is an unordered set of Member AS Numbers in the local confederation that the UPDATE message has traversed. Both extend the AS_PATH segment type field.

bgp, routing