Autonomous System Confederations for BGP
RFC 3065
| Document | Type |
RFC - Proposed Standard
(February 2001; Errata)
Obsoleted by RFC 5065
Obsoletes RFC 1965
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf htmlized with errata bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 3065 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group P. Traina
Request for Comments: 3065 Juniper Networks, Inc.
Obsoletes: 1965 D. McPherson
Category: Standards Track Amber Networks, Inc.
J. Scudder
Cisco Systems, Inc.
February 2001
Autonomous System Confederations for BGP
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
The Border Gateway Protocol (BGP) is an inter-autonomous system
routing protocol designed for Transmission Control Protocol/Internet
Protocol (TCP/IP) networks. BGP requires that all BGP speakers
within a single autonomous system (AS) must be fully meshed. This
represents a serious scaling problem that has been well documented in
a number of proposals.
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.
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].
Traina, et al. Standards Track [Page 1]
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 [Page 2]
RFC 3065 Autonomous System Confederations for BGP February 2001
AS_PATH attribute. For example, one may choose to consider all BGP
speakers in a geographic region as a single entity. In addition to
potential improvements in routing policy control, if techniques such
as those presented here or in [5] are not employed, [1] requires BGP
speakers in the same autonomous system to establish a full mesh of
TCP connections among all speakers for the purpose of exchanging
exterior routing information. In autonomous systems the number of
intra-domain connections that need to be maintained by each border
router can become significant.
Subdividing a large autonomous system allows a significant reduction
in the total number of intra-domain BGP connections, as the
connectivity requirements simplify to the model used for inter-domain
connections.
Unfortunately subdividing an autonomous system may increase the
Show full document text