idnits 2.17.1 draft-ietf-idr-bgp-confed-rfc1965bis-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 ([4], [3,5], [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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC 2119' on line 56 ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1863 (ref. '3') (Obsoleted by RFC 4223) ** Obsolete normative reference: RFC 1965 (ref. '4') (Obsoleted by RFC 3065) ** Obsolete normative reference: RFC 2796 (ref. '5') (Obsoleted by RFC 4456) ** Obsolete normative reference: RFC 2385 (ref. '6') (Obsoleted by RFC 5925) Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Paul Traina 2 INTERNET DRAFT Juniper Networks, Inc. 3 Danny McPherson 4 Amber Networks, Inc. 5 John G. Scudder 6 September 2000 Cisco Systems, Inc. 8 Autonomous System Confederations for BGP 9 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 2. Abstract 34 The Border Gateway Protocol [1] is an inter-autonomous system routing 35 protocol designed for TCP/IP networks. BGP, as defined in [1], 36 requires that all BGP speakers within a single AS must be fully 37 meshed. This represents a serious scaling problem that has been well 38 documented in a number of proposals [3,5]. 40 This document describes an extension to BGP which may be used to 41 create a confederation of autonomous systems that is represented as a 42 single autonomous system to BGP peers external to the confederation, 43 thereby removing the "full mesh" requirement. The intention of this 44 extension is to aid in policy administration and reduce the 45 management complexity of maintaining a large autonomous system. 47 This document is a revision of RFC 1965 [4] and includes editorial 48 changes, clarifications and corrections based on the deployment 49 experience with BGP Confederations. 51 3. Specification of Requirements 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC 2119]. 57 4. Introduction 59 As currently defined, BGP requires that all BGP speakers within a 60 single AS must be fully meshed. The result is that for n BGP 61 speakers within an AS n*(n-1)/2 unique IBGP sessions are required. 62 This "full mesh" requirement clearly does not scale when there are a 63 large number of IBGP speakers within the autonomous system, as is 64 common in many networks today. 66 This scaling problem has been well documented and a number of 67 proposals have been made to alleviate this [3,5]. This document 68 represents another alternative in alleviating the need for a "full 69 mesh" and is known as "Autonomous System Confederations for BGP", or 70 simply, "BGP Confederations". It can also be said the BGP 71 Confederations MAY provide improvements in routing policy control. 73 This document is a revision of RFC 1965 [4] and it includes editorial 74 changes, clarifications and corrections based on the deployment 75 experience with BGP Confederations. These revisions are summarized 76 in Appendix A. 78 5. Terms and Definitions 80 AS Confederation 82 A collection of autonomous systems advertised as a single AS 83 number to BGP speakers that are not members of the confederation. 85 AS Confederation Identifier 87 An externally visible autonomous system number that identifies the 88 confederation as a whole. 90 Member-AS 92 An autonomous system that is contained in a given AS 93 confederation. 95 Member-AS Number 97 An autonomous system number visible only internal to a BGP 98 confederation. 100 6. Discussion 102 It may be useful to subdivide autonomous systems with a very large 103 number of BGP speakers into smaller domains for purposes of 104 controlling routing policy via information contained in the BGP 105 AS_PATH attribute. For example, one may choose to consider all BGP 106 speakers in a geographic region as a single entity. In addition to 107 potential improvements in routing policy control, if techniques such 108 as those presented here or in [5] are not employed, [1] requires BGP 109 speakers in the same autonomous system to establish a full mesh of 110 TCP connections among all speakers for the purpose of exchanging 111 exterior routing information. In autonomous systems the number of 112 intra-domain connections that need to be maintained by each border 113 router can become significant. 115 Subdividing a large autonomous system allows a significant reduction 116 in the total number of intra-domain BGP connections, as the 117 connectivity requirements simplify to the model used for inter-domain 118 connections. 120 Unfortunately subdividing an autonomous system may increase the 121 complexity of routing policy based on AS_PATH information for all 122 members of the Internet. Additionally, this division increases the 123 maintenance overhead of coordinating external peering when the 124 internal topology of this collection of autonomous systems is 125 modified. 127 Finally, dividing a large AS may unnecessarily increase the length of 128 the sequence portions of the AS_PATH attribute. Several common BGP 129 implementations can use the number of "AS hops" required to reach a 130 given destination as part of the path selection criteria. While this 131 is not an optimal method of determining route preference, given the 132 lack of other in-band information, it provides a reasonable default 133 behavior which is widely used across the Internet. Therefore, 134 division of an autonomous system into separate systems may adversely 135 affect optimal routing of packets through the Internet. 137 However, there is usually no need to expose the internal topology of 138 this divided autonomous system, which means it is possible to regard 139 a collection of autonomous systems under a common administration as a 140 single entity or autonomous system when viewed from outside the 141 confines of the confederation of autonomous systems itself. 143 7. AS_CONFED Segment Type Extension 145 Currently, BGP specifies that the AS_PATH attribute is a well-known 146 mandatory attribute that is composed of a sequence of AS path 147 segments. Each AS path segment is represented by a triple . 150 In [1], the path segment type is a 1-octet long field with the two 151 following values defined: 153 Value Segment Type 155 1 AS_SET: unordered set of ASs a route in the 156 UPDATE message has traversed 158 2 AS_SEQUENCE: ordered set of ASs a route in 159 the UPDATE message has traversed 161 This document reserves two additional segment types: 163 3 AS_CONFED_SEQUENCE: ordered set of Member AS Numbers 164 in the local confederation that the UPDATE message has 165 traversed 167 4 AS_CONFED_SET: unordered set of Member AS Numbers in 168 the local confederation that the UPDATE message has 169 traversed 171 8. Operation 173 A member of a BGP confederation will use its AS Confederation ID in 174 all transactions with peers that are not members of its 175 confederation. This confederation identifier is considered to be the 176 "externally visible" AS number and this number is used in OPEN 177 messages and advertised in the AS_PATH attribute. 179 A member of a BGP confederation will use its Routing Domain ID in all 180 transactions with peers that are members of the same confederation as 181 the given router. 183 A BGP speaker receiving an AS_PATH attribute containing an autonomous 184 system matching its own confederation shall treat the path in the 185 same fashion as if it had received a path containing its own AS 186 number. 188 A BGP speaker receiving an AS_PATH attribute containing an 189 AS_CONFED_SEQUENCE or AS_CONFED_SET which contains its own Member AS 190 Number shall treat the path in the same fashion as if it had received 191 a path containing its own AS number. 193 8.1. AS_PATH Modification Rules 195 Section 5.1.2 of [1] is replaced with the following text: 197 When a BGP speaker propagates a route which it has learned from 198 another BGP speaker's UPDATE message, it shall modify the route's 199 AS_PATH attribute based on the location of the BGP speaker to which 200 the route will be sent: 202 a) When a given BGP speaker advertises the route to another BGP 203 speaker located in its own autonomous system, the advertising speaker 204 shall not modify the AS_PATH attribute associated with the route. 206 b) When a given BGP speaker advertises the route to a BGP speaker 207 located in a neighboring autonomous system that is a member of the 208 local autonomous system confederation, then the advertising speaker 209 shall update the AS_PATH attribute as follows: 211 1) if the first path segment of the AS_PATH is of type 212 AS_CONFED_SEQUENCE, the local system shall prepend its own AS 213 number as the last element of the sequence (put it in the 214 leftmost position). 216 2) if the first path segment of the AS_PATH is not of type 217 AS_CONFED_SEQUENCE the local system shall prepend a new path 218 segment of type AS_CONFED_SEQUENCE to the AS_PATH, including 219 its own confederation identifier in that segment. 221 c) When a given BGP speaker advertises the route to a BGP speaker 222 located in a neighboring autonomous system that is not a member of 223 the current autonomous system confederation, the advertising speaker 224 shall update the AS_PATH attribute as follows: 226 1) if the first path segment of the AS_PATH is of type 227 AS_CONFED_SEQUENCE, that segment and any immediately following 228 segments of the type AS_CONFED_SET or AS_CONFED_SEQUENCE are 229 removed from the AS_PATH attribute, leaving the sanitized 230 AS_PATH attribute to be operated on by steps 2, or 3. 232 2) if the first path segment of the remaining AS_PATH is of 233 type AS_SEQUENCE, the local system shall prepend its own 234 confederation ID as the last element of the sequence (put it 235 in the leftmost position). 237 3) if there are no path segments following the removal of the 238 first AS_CONFED_SET/AS_CONFED_SEQUENCE segments, or if the 239 first path segment of the remaining AS_PATH is of type AS_SET 240 the local system shall prepend a new path segment of type 241 AS_SEQUENCE to the AS_PATH, including its own confederation 242 ID in that segment. 244 When a BGP speaker originates a route: 246 a) the originating speaker shall include an empty AS_PATH attribute 247 in all UPDATE messages sent to BGP speakers located in its own Member 248 AS Number. (An empty AS_PATH attribute is one whose length field 249 contains the value zero). 251 b) the originating speaker shall include its own Member AS Number in 252 an AS_CONFED_SEQUENCE segment of the AS_PATH attribute of all UPDATE 253 messages sent to BGP speakers located in neighboring Member-AS that 254 are members of the local confederation (i.e., the originating 255 speaker's Member AS Number will be the only entry in the AS_PATH 256 attribute). 258 c) the originating speaker shall include its own autonomous system in 259 an AS_SEQUENCE segment of the AS_PATH attribute of all UPDATE 260 messages sent to BGP speakers located in neighboring autonomous 261 systems that are not members of the local confederation. (In this 262 case, the autonomous system number of the originating speaker's 263 member confederation will be the only entry in the AS_PATH 264 attribute). 266 9. Common Administration Issues 268 It is reasonable for member ASs of a confederation to share a common 269 administration and IGP information for the entire confederation. 271 It shall be legal for a BGP speaker to advertise an unchanged 272 NEXT_HOP and MULTI_EXIT_DISCRIMINATOR (MED) attribute to peers in a 273 neighboring AS within the same confederation. In addition, the 274 restriction against sending the LOCAL_PREFERENCE attribute to peers 275 in a neighboring AS within the same confederation is removed. Path 276 selection criteria for information received from members inside a 277 confederation MUST follow the same rules used for information 278 received from members inside the same autonomous system, as specified 279 in [1]. 281 10. Compatability Considerations 283 All BGP speakers participating in a confederation must recognize the 284 AS_CONFED_SET and AS_CONFED_SEQUENCE segment type extensions to the 285 AS_PATH attribute. 287 Any BGP speaker not supporting these extensions will generate a 288 notification message specifying an "UPDATE Message Error" and a sub- 289 code of "Malformed AS_PATH". 291 This compatibility issue implies that all BGP speakers participating 292 in a confederation MUST support BGP confederations. However, BGP 293 speakers outside the confederation need not support these extensions. 295 11. Deployment Considerations 297 BGP confederations have been widely deployed throughout the Internet 298 for a number of years and are supported by multiple vendors. 300 Improper configuration of BGP confederations can cause routing 301 information within an AS to be duplicated unnecessarily. This 302 duplication of information will waste system resources, cause 303 unnecessary route flaps, and delay convergence. 305 Care should be taken to manually filter duplicate advertisements 306 caused by reachability information being relayed through multiple 307 member autonomous systems based upon the topology and redundancy 308 requirements of the confederation. 310 Additionally, confederations (as well as route reflectors), by 311 excluding different reachability information from consideration at 312 different locations in a confederation, have been shown to cause 313 permanent oscillation between candidate routes when using the tie 314 breaking rules required by BGP[1]. Care must be taken when selecting 315 MED values and tie breaking policy to avoid these situations. 317 One potential way to avoid this is by configuring inter-Member-AS IGP 318 metrics higher than intra-Member-AS IGP metrics and/or using other 319 tie breaking policies to avoid BGP route selection based on 320 imcomparable MEDs. 322 12. Security Considerations 324 This extension to BGP does not change the underlying security issues 325 inherent in the existing BGP, such as those defined in [6]. 327 13. Acknowledgments 329 The general concept of BGP confederations was taken from IDRP's 330 Routing Domain Confederations [2]. Some of the introductory text in 331 this document was taken from [5]. 333 The authors would like to acknowledge Bruce Cole of Juniper Networks 334 for his implementation feedback and extensive analysis of the 335 limitations of the protocol extensions described in this document and 336 [5]. We would also like to acknowledge Srihari Ramachandra of Cisco 337 Systems, Inc. for his feedback. 339 Finally, we'd like to acknowledge Ravi Chandra and Yakov Rekhter for 340 providing constructive and valuable feedback on earlier versions of 341 this document. 343 Appendix A, Comparison with RFC 1965 345 The most notable change from [1] is that of reversing the values 346 AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in 347 section "AS_CONFED Segment Type Extension". The reasoning for this 348 is that in the initial implemention, which was already widely 349 deployed, they were implemented backwards from [4], and as such, 350 subsequent implementations implemented them backwards as well. In 351 order to foster interoperability and compliance with deployed 352 implementations, they've therefore been changed here as well. 354 The "Compatibility Discussion" was removed and incorporated into 355 other discussions in the document. Also, the mention of hierarchial 356 confederations is removed. The use of the term "Routing Domain 357 Identifier" was replaced with Member AS Number. 359 Finally, the "Deployment Considerations" section was expanded a few 360 subtle grammar changes were made and a bit more introductory text was 361 added. 363 14. References 365 [1] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 366 RFC 1771, March 1995. 368 [2] Kunzinger, C., Editor, "Inter-Domain Routing Protocol", ISO/IEC 369 10747, October 1993. 371 [3] Haskin, D., "A BGP/IDRP Route Server alternative to a full 372 mesh routing", RFC 1863, October 1995. 374 [4] Traina, P. "Autonomous System Confederations for BGP", RFC 375 1965, June 1996. 377 [5] Bates, T., Chandra, R. and Chen, E., "BGP Route Reflection 378 An Alternative to Full Mesh IBGP", RFC 2796, April 2000. 380 [6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Sig- 381 nature Option", RFC2385, August 1998. 383 15. Authors' Address 385 Paul Traina 386 Juniper Networks, Inc. 387 1194 N. Mathilda Ave. 388 Sunnyvale, CA 94089 USA 389 Phone: +1 408 745-2000 390 Email: pst+confed@juniper.net 392 Danny McPherson 393 Amber Networks, Inc. 394 2465 Augustine Drive 395 Santa Clara, CA 95054 396 Phone: +1 408.486.6336 397 Email: danny@ambernetworks.com 399 John G. Scudder 400 Cisco Systems, Inc. 401 170 West Tasman Drive 402 San Jose, CA 95134 403 Phone: +1 734.669.8800 404 Email: jgs@cisco.com