idnits 2.17.1 draft-ietf-idr-rfc3065bis-01.txt: 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: ---------------------------------------------------------------------------- == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 2003) is 7496 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) -- Looks like a reference, but probably isn't: 'RFC 2119' on line 36 == Unused Reference: '8' is defined on line 453, but no explicit reference was found in the text ** 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 3065 (ref. '5') (Obsoleted by RFC 5065) ** Obsolete normative reference: RFC 2796 (ref. '6') (Obsoleted by RFC 4456) ** Obsolete normative reference: RFC 2385 (ref. '7') (Obsoleted by RFC 5925) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Paul Traina 3 Danny McPherson 4 Arbor Networks 5 John Scudder 6 Cisco Systems 7 Expires: April 2004 October 2003 9 Autonomous System Confederations for BGP 10 12 Status of this Document 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC 2119]. 37 This document is a product of the . Comments should be addressed to 38 the authors, or the mailing list at 40 Copyright Notice 42 Copyright (C) The Internet Society (2003). All Rights Reserved. 44 Abstract 46 The Border Gateway Protocol (BGP) is an inter-autonomous system 47 routing protocol designed for Transmission Control Protocol/Internet 48 Protocol (TCP/IP) networks. BGP requires that all BGP speakers 49 within a single autonomous system (AS) must be fully meshed. This 50 represents a serious scaling problem that has been well documented in 51 a number of proposals. 53 This document describes an extension to BGP which may be used to 54 create a confederation of autonomous systems that is represented as a 55 single autonomous system to BGP peers external to the confederation, 56 thereby removing the "full mesh" requirement. The intention of this 57 extension is to aid in policy administration and reduce the 58 management complexity of maintaining a large autonomous system. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. AS_CONFED Segement Type Extension. . . . . . . . . . . . . . . 6 66 5. Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. AS_PATH Modification Rules. . . . . . . . . . . . . . . . . 7 68 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7. Common Administration Issues . . . . . . . . . . . . . . . . . 9 70 7.1. MED and LOCAL_PREF Handling . . . . . . . . . . . . . . . . 9 71 7.2. AS_PATH and Path Selection. . . . . . . . . . . . . . . . . 9 72 8. Compatability Considerations . . . . . . . . . . . . . . . . . 10 73 9. Deployment Considerations. . . . . . . . . . . . . . . . . . . 10 74 10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 11 75 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 76 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 13. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 14. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 14 79 15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 As currently defined, BGP requires that all BGP speakers within a 84 single AS must be fully meshed. The result is that for n BGP 85 speakers within an AS n*(n-1)/2 unique IBGP sessions are required. 86 This "full mesh" requirement clearly does not scale when there are a 87 large number of IBGP speakers within the autonomous system, as is 88 common in many networks today. 90 This scaling problem has been well documented and a number of 91 proposals have been made to alleviate this [3,6]. This document 92 presents another alternative alleviating the need for a "full mesh" 93 and is known as "Autonomous System Confederations for BGP", or 94 simply, "BGP Confederations". It has also been observed that BGP 95 Confederations may provide improvements in routing policy control. 97 This document is a revision of RFC 3065 [5], which is itself a 98 revision to RFC 1965 [4]. It includes editorial changes, 99 clarifications and corrections based on deployment experience with 100 BGP Confederations. These revisions are summarized in Appendices A 101 and B. 103 2. Terminology 105 AS Confederation 107 A collection of autonomous systems advertised as a single AS 108 number to BGP speakers that are not members of the 109 confederation. 111 AS Confederation Identifier 113 An externally visible autonomous system number that identifies 114 the confederation as a whole. 116 Member Autonomous System (Member-AS) 118 An autonomous system that is contained in a given AS 119 confederation. Note that "Member Autonomous System" and 120 "Member-AS" are used entirely interchangeably throughout 121 this document. 123 Member-AS Number 124 An autonomous system number visible only within a BGP 125 confederation. 127 3. Discussion 129 It may be useful to subdivide autonomous systems with a very large 130 number of BGP speakers into smaller domains for purposes of 131 controlling routing policy via information contained in the BGP 132 AS_PATH attribute. For example, one may choose to consider all BGP 133 speakers in a geographic region as a single entity. 135 In addition to potential improvements in routing policy control, if 136 techniques such as those presented here or in [6] are not employed, 137 [1] requires BGP speakers in the same autonomous system to establish 138 a full mesh of TCP connections among all speakers for the purpose of 139 exchanging exterior routing information. In autonomous systems the 140 number of intra-domain connections that need to be maintained by each 141 border router can become significant. 143 Subdividing a large autonomous system allows a significant reduction 144 in the total number of intra-domain BGP connections, as the 145 connectivity requirements simplify to the model used for inter-domain 146 connections. 148 Unfortunately, subdividing an autonomous system may increase the 149 complexity of routing policy based on AS_PATH information for all 150 members of the Internet. Additionally, this division increases the 151 maintenance overhead of coordinating external peering when the 152 internal topology of this collection of autonomous systems is 153 modified. 155 Therefore, division of an autonomous system into separate systems may 156 adversely affect optimal routing of packets through the Internet. 158 However, there is usually no need to expose the internal topology of 159 this divided autonomous system, which means it is possible to regard 160 a collection of autonomous systems under a common administration as a 161 single entity or autonomous system, when viewed from outside the 162 confines of the confederation of autonomous systems itself. 164 4. AS_CONFED Segement Type Extension 166 Currently, BGP specifies that the AS_PATH attribute is a well-known 167 mandatory attribute that is composed of a sequence of AS path 168 segments. Each AS path segment is represented by a triple . 171 In [1], the path segment type is a 1-octet long field with the two 172 following values defined: 174 Value Segment Type 176 1 AS_SET: unordered set of autonomous systems a route in 177 the UPDATE message has traversed 179 2 AS_SEQUENCE: ordered set of autonomous systems a route 180 in the UPDATE message has traversed 182 This document specifies two additional segment types: 184 3 AS_CONFED_SEQUENCE: ordered set of Member Autonomous 185 Systems in the local confederation that the UPDATE message 186 has traversed 188 4 AS_CONFED_SET: unordered set of Member Autonomous Systems 189 in the local confederation that the UPDATE message has 190 traversed 192 5. Operation 194 A member of a BGP confederation will use its AS Confederation 195 Identifier in all transactions with peers that are not members of its 196 confederation. This confederation identifier is the "externally 197 visible" AS number and this number is used in OPEN messages and 198 advertised in the AS_PATH attribute. 200 A member of a BGP confederation will use its Member-AS Number in all 201 transactions with peers that are members of the same confederation as 202 the given BGP speaker. 204 A BGP speaker receiving an AS_PATH attribute containing an autonomous 205 system matching its own AS Confederation Identifier shall treat the 206 path in the same fashion as if it had received a path containing its 207 own AS number. 209 A BGP speaker receiving an AS_PATH attribute containing an 210 AS_CONFED_SEQUENCE or AS_CONFED_SET which contains its own Member-AS 211 Number shall treat the path in the same fashion as if it had received 212 a path containing its own AS number. 214 5.1. AS_PATH Modification Rules 216 When implementing BGP Confederations Section 5.1.2 of [1] is replaced 217 with the following text: 219 When a BGP speaker propagates a route which it has learned from 220 another BGP speaker's UPDATE message, it shall modify the route's 221 AS_PATH attribute based on the location of the BGP speaker to which 222 the route will be sent: 224 a) When a given BGP speaker advertises the route to another BGP 225 speaker located in its own autonomous system, the advertising 226 speaker shall not modify the AS_PATH attribute associated with the 227 route. 229 b) When a given BGP speaker advertises the route to a BGP speaker 230 located in a neighboring autonomous system that is a member of 231 the local confederation, the advertising speaker shall update the 232 AS_PATH attribute as follows: 234 1) if the first path segment of the AS_PATH is of type 235 AS_CONFED_SEQUENCE, the local system shall prepend its own 236 Member-AS Number as the last element of the sequence (put 237 it in the leftmost position). 239 2) if the first path segment of the AS_PATH is not of type 240 AS_CONFED_SEQUENCE the local system shall prepend a new path 241 segment of type AS_CONFED_SEQUENCE to the AS_PATH, including 242 its own Member-AS Number in that segment. 244 c) When a given BGP speaker advertises the route to a BGP speaker 245 located in a neighboring autonomous system that is not a member of 246 the local confederation, the advertising speaker shall update the 247 AS_PATH attribute as follows: 249 1) if any path segments of the AS_PATH are of the type 250 AS_CONFED_SEQUENCE or AS_CONFED_SET, those segments shall 251 be removed from the AS_PATH attribute, leaving the sanitized 252 AS_PATH attribute to be operated on by steps 2 or 3. 254 2) if the first path segment of the remaining AS_PATH is of type 255 AS_SEQUENCE, the local system shall prepend its own 256 AS Confederation Identifier as the last element of the sequence 257 (put it in the leftmost position). 259 3) if there are no path segments following the removal of the 260 first AS_CONFED_SET/AS_CONFED_SEQUENCE segments, or if the 261 first path segment of the remaining AS_PATH is not of type 262 AS_SEQUENCE the local system shall prepend a new path segment 263 of type AS_SEQUENCE to the AS_PATH, including its own AS 264 Confederation Identifier in that segment. 266 When a BGP speaker originates a route: 268 a) the originating speaker shall include an empty AS_PATH attribute 269 in all UPDATE messages sent to BGP speakers residing within the 270 same Member-AS. (An empty AS_PATH attribute is one whose length 271 field contains the value zero). 273 b) the originating speaker shall include its own Member-AS Number in 274 an AS_CONFED_SEQUENCE segment of the AS_PATH attribute of all 275 UPDATE messages sent to BGP speakers located in neighboring 276 Member Autonomous Systems that are members of the local 277 confederation (i.e., the originating speaker's Member-AS Number 278 will be the only entry in the AS_PATH attribute). 280 c) the originating speaker shall include its own AS Confederation 281 Identifier in an AS_SEQUENCE segment of the AS_PATH attribute of 282 all UPDATE messages sent to BGP speakers located in neighboring 283 autonomous systems that are not members of the local 284 confederation. (In this case, the originating speaker's AS 285 Confederation Identifier will be the only entry in the AS_PATH 286 attribute). 288 6. Error Handling 290 A BGP speaker MUST NOT transmit updates containing AS_CONFED_SET or 291 AS_CONFED_SEQUENCE attributes to peers that are not members of the 292 local confederation. 294 It is an error for a BGP speaker to receive an update message with an 295 AS_PATH attribute which contains AS_CONFED_SEQUENCE or AS_CONFED_SET 296 segments from a neighbor which is not located in the same 297 confederation. If a BGP speaker receives such an update message, it 298 SHALL treat the message as having a malformed AS_PATH according to 299 the procedures of [1] Section 6.3 ("UPDATE message error handling"). 301 It is a error for a BGP speaker to receive an update message from a 302 confederation peer which does not have AS_CONFED_SEQUENCE as the 303 first segment. If a BGP speaker receives such an update message, it 304 SHALL treat the message as having a malformed AS_PATH according to 305 the procedures of [1] Section 6.3 ("Update message error handling"). 307 7. Common Administration Issues 309 It is reasonable for Member Autonomous Systems of a confederation to 310 share a common administration and IGP information for the entire 311 confederation. 313 7.1. MED and LOCAL_PREF Handling 315 It shall be legal for a BGP speaker to advertise an unchanged 316 NEXT_HOP and MULTI_EXIT_DISC (MED) attribute to peers in a 317 neighboring Member-AS of the local confederation. 319 An implementation MAY compare MEDs received from a Member-AS via 320 multiple paths. An implementation MAY compare MEDs from different 321 Member Autonomous Systems of the same confederation. 323 In addition, the restriction against sending the LOCAL_PREF attribute 324 to peers in a neighboring AS within the same confederation is 325 removed. 327 7.2. AS_PATH and Path Selection 329 Path selection criteria for information received from members inside 330 a confederation MUST follow the same rules used for information 331 received from members inside the same autonomous system, as specified 332 in [1]. 334 In addition, the following rules SHALL be applied: 336 1) If the AS_PATH is internal to the local confederation (i.e., there 337 are only AS_CONFED_* segments) consider the neighbor AS to be the 338 local AS. 340 2) Otherwise, if the first segment in the path which is not an 341 AS_CONFED_SEQUENCE or AS_CONFED_SET is an AS_SEQUENCE, consider 342 the neighbor AS to be the leftmost AS_SEQUENCE AS. 344 8. Compatability Considerations 346 All BGP speakers participating as member of a confederation MUST 347 recognize the AS_CONFED_SET and AS_CONFED_SEQUENCE segment type 348 extensions to the AS_PATH attribute. 350 Any BGP speaker not supporting these extensions will generate a 351 NOTIFICATION message specifying an "UPDATE Message Error" and a sub- 352 code of "Malformed AS_PATH". 354 This compatibility issue implies that all BGP speakers participating 355 in a confederation MUST support BGP confederations. However, BGP 356 speakers outside the confederation need not support these extensions. 358 9. Deployment Considerations 360 BGP confederations have been widely deployed throughout the Internet 361 for a number of years and are supported by multiple vendors. 363 Improper configuration of BGP confederations can cause routing 364 information within an AS to be duplicated unnecessarily. This 365 duplication of information will waste system resources, cause 366 unnecessary route flaps, and delay convergence. 368 Care should be taken to manually filter duplicate advertisements 369 caused by reachability information being relayed through multiple 370 Member Autonomous Systems based upon the topology and redundancy 371 requirements of the confederation. 373 Additionally, confederations (as well as route reflectors), by 374 excluding different reachability information from consideration at 375 different locations in a confederation, have been shown to cause 376 permanent oscillation between candidate routes when using the tie 377 breaking rules required by BGP [1]. Care must be taken when 378 selecting MED values and tie breaking policy to avoid these 379 situations. 381 One potential way to avoid this is by configuring inter-Member-AS IGP 382 metrics higher than intra-Member-AS IGP metrics and/or using other 383 tie breaking policies to avoid BGP route selection based on 384 incomparable MEDs. 386 10. Intellectual Property 388 The IETF takes no position regarding the validity or scope of any 389 intellectual property or other rights that might be claimed to 390 pertain to the implementation or use of the technology described in 391 this document or the extent to which any license under such rights 392 might or might not be available; neither does it represent that it 393 has made any effort to identify any such rights. Information on the 394 IETF's procedures with respect to rights in standards-track and 395 standards-related documentation can be found in BCP-11. Copies of 396 claims of rights made available for publication and any assurances of 397 licenses to be made available, or the result of an attempt made to 398 obtain a general license or permission for the use of such 399 proprietary rights by implementors or users of this specification can 400 be obtained from the IETF Secretariat. 402 The IETF invites any interested party to bring to its attention any 403 copyrights, patents or patent applications, or other proprietary 404 rights which may cover technology that may be required to practice 405 this standard. Please address the information to the IETF Executive 406 Director. 408 11. Acknowledgments 410 The general concept of BGP confederations was taken from IDRP's 411 Routing Domain Confederations [2]. Some of the introductory text in 412 this document was taken from [6]. 414 The authors would like to acknowledge Bruce Cole for his 415 implementation feedback and extensive analysis of the limitations of 416 the protocol extensions described in this document and [5]. We would 417 also like to acknowledge Srihari Ramachandra, Alex Zinin, Naresh 418 Kumar Paliwal, Jeffrey Haas and Bruno Rijsman for their feedback and 419 suggestions. 421 Finally, we'd like to acknowledge Ravi Chandra and Yakov Rekhter for 422 providing constructive and valuable feedback on earlier versions of 423 this specification. 425 12. Security Considerations 427 This extension to BGP does not change the underlying security issues 428 inherent in the existing BGP, such as those defined in [7]. 430 13. References 432 [1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 433 1771, March 1995. 435 [2] Kunzinger, C., Editor, "Inter-Domain Routing Protocol", ISO/IEC 436 10747, October 1993. 438 [3] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh 439 routing", RFC 1863, October 1995. 441 [4] Traina, P. "Autonomous System Confederations for BGP", RFC 1965, 442 June 1996. 444 [5] Traina, P., McPherson, D. and Scudder, J., "Autonomous System 445 Confederations for BGP", RFC 3065, February 2001. 447 [6] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection An 448 Alternative to Full Mesh IBGP", RFC 2796, April 2000. 450 [7] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 451 Signature Option", RFC 2385, August 1998. 453 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 454 Levels", RFC 2119, March 1997. 456 14. Authors' Addresses 458 Paul Traina 459 EMail: pst+confed@spamcatcher.bogus.com 461 Danny McPherson 462 Arbor Networks 463 EMail: danny@arbor.net 465 John G. Scudder 466 Cisco Systems, Inc. 467 170 West Tasman Drive 468 San Jose, CA 95134 469 Phone: +1 734.302.4128 470 EMail: jgs@cisco.com 472 15. Full Copyright Statement 474 Copyright (C) The Internet Society (2003). All Rights Reserved. 476 This document and translations of it may be copied and furnished to 477 others, and derivative works that comment on or otherwise explain it 478 or assist in its implementation may be prepared, copied, published 479 and distributed, in whole or in part, without restriction of any 480 kind, provided that the above copyright notice and this paragraph are 481 included on all such copies and derivative works. However, this 482 document itself may not be modified in any way, such as by removing 483 the copyright notice or references to the Internet Society or other 484 Internet organizations, except as needed for the purpose of 485 developing Internet standards in which case the procedures for 486 copyrights defined in the Internet Standards process must be 487 followed, or as required to translate it into languages other than 488 English. 490 The limited permissions granted above are perpetual and will not be 491 revoked by the Internet Society or its successors or assigns. 493 This document and the information contained herein is provided on an 494 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 495 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 496 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 497 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 498 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.