1. Introduction
As originally 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 Internal BGP (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, such as [RFC2796] and [RFC1863] (made historic by [RFC4223]). This document presents another alternative alleviating the need for a "full mesh" and is known as "Autonomous System Confederations for BGP", or simply, "BGP confederations". It has also been observed that BGP confederations may provide improvements in routing policy control.
This document is a revision of, and obsoletes, [RFC3065], which is itself a revision of [RFC1965]. It includes editorial changes, terminology clarifications, and more explicit protocol specifications based on extensive implementation and deployment experience with BGP Confederations.
1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology
AS Confederation A collection of autonomous systems represented and advertised as a single AS number to BGP speakers that are not members of the local BGP confederation.
AS Confederation Identifier An externally visible autonomous system number that identifies a BGP confederation as a whole.
Member Autonomous System (Member-AS) An autonomous system that is contained in a given AS confederation. Note that "Member Autonomous System" and "Member-AS" are used entirely interchangeably throughout this document.
Member-AS Number An autonomous system number identifier visible only within a BGP confederation, and used to represent a Member-AS within that confederation.