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