RFC 3065 (rfc3065) - Page 2 of 11
Autonomous System Confederations for BGP
Alternative Format: Original Text Document
RFC 3065 Autonomous System Confederations for BGP February 2001
2. Introduction
As currently defined, BGP requires that all BGP speakers within a
single AS must be fully meshed. The result is that for n BGP
speakers within an AS n*(n-1)/2 unique IBGP sessions are required.
This "full mesh" requirement clearly does not scale when there are a
large number of IBGP speakers within the autonomous system, as is
common in many networks today.
This scaling problem has been well documented and a number of
proposals have been made to alleviate this [3,5]. This document
represents another alternative in alleviating the need for a "full
mesh" and is known as "Autonomous System Confederations for BGP", or
simply, "BGP Confederations". It can also be said the BGP
Confederations MAY provide improvements in routing policy control.
This document is a revision of RFC 1965 [4] and it includes editorial
changes, clarifications and corrections based on the deployment
experience with BGP Confederations. These revisions are summarized
in Appendix A.
3. Terms and Definitions
AS Confederation
A collection of autonomous systems advertised as a single AS
number to BGP speakers that are not members of the confederation.
AS Confederation Identifier
An externally visible autonomous system number that identifies the
confederation as a whole.
Member-AS
An autonomous system that is contained in a given AS
confederation.
Member-AS Number
An autonomous system number visible only internal to a BGP
confederation.
4. Discussion
It may be useful to subdivide autonomous systems with a very large
number of BGP speakers into smaller domains for purposes of
controlling routing policy via information contained in the BGP
Traina, et al. Standards Track