idnits 2.17.1 draft-ietf-idr-bgp-confed-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 27, 1996) is 10229 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Paul Traina 2 INTERNET DRAFT cisco Systems 3 March 27, 1996 5 Autonomous System Confederations for BGP 7 Status of this Memo 9 This memo provides information for the Internet community. It does 10 not specify an Internet standard. Distribution of this memo is 11 unlimited. 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress." 24 Please check the I-D abstract listing contained in each Internet 25 Draft directory to learn the current status of this or any other 26 Internet Draft. 28 Abstract 30 Border Gateway Protocol [1] is an inter-autonomous system routing 31 protocol designed for TCP/IP networks. 33 This document describes an extension to BGP which may be used to 34 create a confederation of autonomous systems which is represented as 35 one single autonomous system to BGP peers external to the 36 confederation. 38 The intention of this extension is to aid in policy administration 39 and reduce the management complexity of maintaining a large 40 autonomous system. 42 The extension this document describes is widely deployed in the 43 Internet today. 45 Introduction 47 It may be useful to subdivide autonomous systems with a very large 48 number of BGP speakers into smaller domains for purposes of 49 controlling routing policy via information contained in the BGP 50 AS_PATH attribute. For example, one may chose to consider all BGP 51 speakers in a geographic region as a single entity. 53 In addition to improvements in routing policy control, current 54 techniques for deploying BGP among speakers in the same autonomous 55 system establish a full mesh of TCP connections among all speakers 56 for the purpose of exchanging exterior routing information. In 57 autonomous systems the number of intra-domain connections that need 58 to be maintained by each border router can become significant. 60 Subdividing a large autonomous system allows a significant reduction 61 in the total number of intra-domain BGP connections, as the 62 connectivity requirements simplify to the model used for inter-domain 63 connections. 65 Unfortunately subdividing an autonomous system may increase the 66 complexity of policy routing based on AS_PATH information for all 67 members of the Internet. Additionally, this division increases the 68 maintenance overhead of coordinating external peering when the 69 internal topology of this collection of autonomous systems is 70 modified. 72 Finally, dividing a large AS may unnecessarily increase the length of 73 the sequence portions of the AS_PATH attribute. Several common BGP 74 implementations can use the number of "hops" required to reach a 75 given destination as part of the path selection criteria. While this 76 is not an optimal method of determining route preference, given the 77 lack of other in-band information, it provides a reasonable default 78 behavior which is widely used across the Internet. Therefore, 79 division of an autonomous system into separate systems may adversely 80 affect optimal routing of packets through the Internet. 82 However, there is usually no need to expose the internal topology of 83 this divided autonomous system, which means it is possible to regard 84 a collection of autonomous systems under a common administration as a 85 single entity or autonomous system when viewed from outside the 86 confines of the confederation of autonomous systems itself. 88 Terms and Definitions 90 AS Confederation 91 A collection of autonomous systems advertised as a single AS 92 number to BGP speakers that are not members of the confederation. 94 AS Confederation Identifier 95 An externally visible autonomous system number that identifies the 96 confederation as a whole. 98 Member-AS 99 An autonomous system that is contained in a given AS 100 confederation. 102 Overview 104 IDRP[2] has the concept of a routing domain confederation. An IDRP 105 routing domain confederation appears to IDRP speakers external to the 106 confederation as a single administrative entity. This extension is 107 based upon that work. 109 In IDRP, routing domain confederations may be nested within each 110 other or disjoint portions of still larger confederations. The 111 algorithm BGP defines for additions to the AS_PATH attribute imposes 112 an additional restriction that AS confederations must be strictly 113 hierarchical in nature. 115 AS_CONFED segment type extension 117 Currently, BGP specifies that the AS_PATH attribute is a well-known 118 mandatory attribute that is composed of a sequence of AS path 119 segments. Each AS path segment is represented by a type/length/value 120 triple. 122 In [1], the path segment type is a 1-octet long field with the two 123 following values defined: 125 Value Segment Type 127 1 AS_SET: unordered set of ASs a route in the 128 UPDATE message has traversed 130 2 AS_SEQUENCE: ordered set of ASs a route in 131 the UPDATE message has traversed 133 This document reserves two additional segment types: 135 3 AS_CONFED_SET: unordered set of ASs in the local 136 confederation that the UPDATE message 137 has traversed 139 4 AS_CONFED_SEQUENCE: ordered set of ASs in the 140 local confederation that the UPDATE 141 message has traversed 143 Operation 145 A member of a BGP confederation will use its confederation identifier 146 in all transactions with peers that are not members of its 147 confederation. This confederation identifier is considered to be the 148 "externally visible" AS number and this number is used in OPEN 149 messages and advertised in the AS_PATH attribute. 151 A member of a BGP confederation will use its routing domain 152 identifier (the internally visible AS number) in all transactions 153 with peers that are members of the same confederation as the given 154 router. 156 A BGP speaker receiving an AS_PATH attribute containing a 157 confederation ID matching its own confederation shall treat the path 158 in the same fashion as if it had received a path containing its own 159 AS number. 161 AS_PATH modification rules 163 Section 5.1.2 of [1] is replaced with the following text. 165 When a BGP speaker propagates a route which it has learned from 166 another BGP speaker's UPDATE message, it shall modify the route's 167 AS_PATH attribute based on the location of the BGP speaker to which 168 the route will be sent: 170 a) When a given BGP speaker advertises the route to another BGP 171 speaker located in its own autonomous system, the advertising 172 speaker shall not modify the AS_PATH attribute associated with the 173 route. 175 b) When a given BGP speaker advertises the route to a BGP speaker 176 located in a neighboring autonomous system that is a member of the 177 local autonomous system confederation, then the advertising 178 speaker shall update the AS_PATH attribute as follows: 180 1) if the first path segment of the AS_PATH is of type 181 AS_CONFED_SEQUENCE, the local system shall prepend its own AS 182 number as the last element of the sequence (put it in the 183 leftmost position). 185 2) if the first path segment of the AS_PATH is not of type 186 AS_CONFED_SEQUENCE the local system shall prepend a new path 187 segment of type AS_CONFED_SEQUENCE to the AS_PATH, including 188 its own confederation identifier in that segment. 190 c) When a given BGP speaker advertises the route to a BGP speaker 191 located in a neighboring autonomous system that is not a member of 192 the current routing domain confederation, then the advertising 193 speaker shall update the AS_PATH attribute as follows: 195 1) if the first path segment of the AS_PATH is of type 196 AS_CONFED_SEQUENCE, that segment and any immediately following 197 segments of the type AS_CONFED_SET are removed from the AS_PATH 198 attribute, leaving the sanitized AS_PATH attribute to be 199 operated on by steps 2, or 3. 201 2) if the first path segment of the remaining AS_PATH is of 202 type AS_SEQUENCE, the local system shall prepend its own 203 confederation identifier as the last element of the sequence 204 (put it in the leftmost position). 206 3) if there are no path segments following the removal of the 207 first AS_CONFED_SET/AS_CONFED_SEQUENCE segments, or if the 208 first path segment of the remaining AS_PATH is of type AS_SET 209 the local system shall prepend a new path segment of type 210 AS_SEQUENCE to the AS_PATH, including its own confederation 211 identifier in that segment. 213 When a BGP speaker originates a route: 215 a) the originating speaker shall include an empty AS_PATH 216 attribute in all UPDATE messages sent to BGP speakers located in 217 its own autonomous system. (An empty AS_PATH attribute is one 218 whose length field contains the value zero). 220 b) the originating speaker shall include its own AS number in an 221 AS_CONFED_SEQUENCE segment of the AS_PATH attribute of all UPDATE 222 messages sent to BGP speakers located in neighboring autonomous 223 systems that are members of the local confederation. (In this 224 case, the AS number of the originating speaker's member autonomous 225 system number will be the only entry in the AS_PATH attribute). 227 c) the originating speaker shall include its own confederation 228 identifier in a AS_SEQUENCE segment of the AS_PATH attribute of 229 all UPDATE messages sent to BGP speakers located in neighboring 230 autonomous systems that are not members of the local 231 confederation. (In this case, the confederation identifier of the 232 originating speaker's member confederation will be the only entry 233 in the AS_PATH attribute). 235 Common Administration Issues 237 It is reasonable for member ASs of a confederation to share a common 238 administration and IGP information for the entire confederation. 240 It shall be legal for a BGP speaker to advertise an unchanged 241 NEXT_HOP and MULTI_EXIT_DISCRIMINATOR attribute to peers in a 242 neighboring AS within the same confederation. In addition, the 243 restriction against sending the LOCAL_PREFERENCE attribute to peers 244 in a neighboring AS within the same confederation is removed. Path 245 selection criteria for information received from members inside a 246 confederation may follow the same rules used for information received 247 from members inside the same autonomous system. 249 Compatibility 251 All BGP speakers participating in a confederation must recognize the 252 AS_CONFED_SET and AS_CONFED_SEQUENCE segment type extensions to the 253 AS_PATH attribute. 255 Any BGP speaker not supporting these extensions will generate a 256 notification message specifying an "UPDATE Message Error" and a sub- 257 code of "Malformed AS_PATH". 259 This compatibility issue implies that all BGP speakers participating 260 in a confederation must support BGP confederations, however BGP 261 speakers outside the confederation need not support these extensions. 263 Compatibility Discussion 265 We considered the use of a distinct, optional, transitive attribute 266 to carry AS confederation information as opposed to specifying new 267 types in the existing AS path attribute. This would relax the 268 requirement that all BGP speakers participating in a confederation to 269 allow the use of legacy units provided they have no external (i.e. 270 neither inter-AS nor intra-confederation) connectivity. 272 At the time of this writing, an implementation of this extension as 273 documented is widely deployed throughout the Internet, therefore the 274 value of any change that is incompatible with this document must be 275 weighed against the benefit gained from a relaxation of this 276 restriction. 278 Security Considerations 280 Security considerations are not discussed in this memo. 282 Acknowledgments 284 Ravi Chandra and Yakov Rekhter reviewed this document and provided 285 constructive and valuable comments. 287 Author's Address: 289 Paul Traina 290 cisco Systems, Inc. 291 170 W. Tasman Dr. 292 San Jose, CA 95134 293 pst@cisco.com 295 References 297 [1] RFC1771 298 Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", March 299 1995. 301 [2] ISO/IEC 10747 302 Kunzinger, C. Editor, "Inter-Domain Routing Protocol", October 1993