Autonomous System Confederations for BGP
RFC 5065
| Document | Type |
RFC - Draft Standard
(August 2007; Errata)
Obsoletes RFC 3065
|
|
|---|---|---|---|
| Last updated | 2018-12-20 | ||
| Stream | IETF | ||
| Formats | plain text pdf htmlized with errata bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 5065 (Draft Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Bill Fenner | ||
| Send notices to | (None) | ||
Network Working Group P. Traina
Request for Comments: 5065 Blissfully Retired
Obsoletes: 3065 D. McPherson
Category: Standards Track Arbor Networks
J. Scudder
Juniper Networks
August 2007
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 IETF Trust (2007).
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 that 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.
This document obsoletes RFC 3065.
Traina, et al. Standards Track [Page 1]
RFC 5065 August 2007
Table of Contents
1. Introduction ....................................................3
1.1. Specification of Requirements ..............................3
1.2. Terminology ................................................3
2. Discussion ......................................................4
3. AS_CONFED Segment Type Extension ................................5
4. Operation .......................................................5
4.1. AS_PATH Modification Rules .................................6
5. Error Handling ..................................................8
5.1. Error Handling .............................................8
5.2. MED and LOCAL_PREF Handling ................................8
5.3. AS_PATH and Path Selection .................................9
6. Compatibility Considerations ...................................10
7. Deployment Considerations ......................................10
8. Security Considerations ........................................10
9. Acknowledgments ................................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................11
Appendix A. Aggregate Routing Information .........................13
Appendix B. Changes from RFC 3065 .................................13
Traina, et al. Standards Track [Page 2]
RFC 5065 August 2007
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
Show full document text