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 html 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 thisShow full document text