idnits 2.17.1 draft-ietf-idr-bgp-confed-rfc1965bis-01.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 57 ** 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. -------------------------------------------------------------------------------- 2 Network Working Group Paul Traina 3 INTERNET DRAFT Juniper Networks, Inc. 4 Danny McPherson 5 Amber Networks, Inc. 6 John G. Scudder 7 October 2000 Cisco Systems, Inc. 9 Autonomous System Confederations for BGP 10 12 1. Status of this Memo 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 2. Abstract 35 The Border Gateway Protocol [1] is an inter-autonomous system routing 36 protocol designed for TCP/IP networks. BGP, as defined in [1], 37 requires that all BGP speakers within a single AS must be fully 38 meshed. This represents a serious scaling problem that has been well 39 documented in a number of proposals [3,5]. 41 This document describes an extension to BGP which may be used to 42 create a confederation of autonomous systems that is represented as a 43 single autonomous system to BGP peers external to the confederation, 44 thereby removing the "full mesh" requirement. The intention of this 45 extension is to aid in policy administration and reduce the 46 management complexity of maintaining a large autonomous system. 48 This document is a revision of RFC 1965 [4] and includes editorial 49 changes, clarifications and corrections based on the deployment 50 experience with BGP Confederations. 52 3. Specification of Requirements 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC 2119]. 58 4. Introduction 60 As currently defined, BGP requires that all BGP speakers within a 61 single AS must be fully meshed. The result is that for n BGP 62 speakers within an AS n*(n-1)/2 unique IBGP sessions are required. 63 This "full mesh" requirement clearly does not scale when there are a 64 large number of IBGP speakers within the autonomous system, as is 65 common in many networks today. 67 This scaling problem has been well documented and a number of 68 proposals have been made to alleviate this [3,5]. This document 69 represents another alternative in alleviating the need for a "full 70 mesh" and is known as "Autonomous System Confederations for BGP", or 71 simply, "BGP Confederations". It can also be said the BGP 72 Confederations MAY provide improvements in routing policy control. 74 This document is a revision of RFC 1965 [4] and it includes editorial 75 changes, clarifications and corrections based on the deployment 76 experience with BGP Confederations. These revisions are summarized 77 in Appendix A. 79 5. Terms and Definitions 81 AS Confederation 83 A collection of autonomous systems advertised as a single AS 84 number to BGP speakers that are not members of the confederation. 86 AS Confederation Identifier 88 An externally visible autonomous system number that identifies the 89 confederation as a whole. 91 Member-AS 93 An autonomous system that is contained in a given AS 94 confederation. 96 Member-AS Number 98 An autonomous system number visible only internal to a BGP 99 confederation. 101 6. Discussion 103 It may be useful to subdivide autonomous systems with a very large 104 number of BGP speakers into smaller domains for purposes of 105 controlling routing policy via information contained in the BGP 106 AS_PATH attribute. For example, one may choose to consider all BGP 107 speakers in a geographic region as a single entity. In addition to 108 potential improvements in routing policy control, if techniques such 109 as those presented here or in [5] are not employed, [1] requires BGP 110 speakers in the same autonomous system to establish a full mesh of 111 TCP connections among all speakers for the purpose of exchanging 112 exterior routing information. In autonomous systems the number of 113 intra-domain connections that need to be maintained by each border 114 router can become significant. 116 Subdividing a large autonomous system allows a significant reduction 117 in the total number of intra-domain BGP connections, as the 118 connectivity requirements simplify to the model used for inter-domain 119 connections. 121 Unfortunately subdividing an autonomous system may increase the 122 complexity of routing policy based on AS_PATH information for all 123 members of the Internet. Additionally, this division increases the 124 maintenance overhead of coordinating external peering when the 125 internal topology of this collection of autonomous systems is 126 modified. 128 Finally, dividing a large AS may unnecessarily increase the length of 129 the sequence portions of the AS_PATH attribute. Several common BGP 130 implementations can use the number of "AS hops" required to reach a 131 given destination as part of the path selection criteria. While this 132 is not an optimal method of determining route preference, given the 133 lack of other in-band information, it provides a reasonable default 134 behavior which is widely used across the Internet. Therefore, 135 division of an autonomous system into separate systems may adversely 136 affect optimal routing of packets through the Internet. 138 However, there is usually no need to expose the internal topology of 139 this divided autonomous system, which means it is possible to regard 140 a collection of autonomous systems under a common administration as a 141 single entity or autonomous system when viewed from outside the 142 confines of the confederation of autonomous systems itself. 144 7. AS_CONFED Segment Type Extension 146 Currently, BGP specifies that the AS_PATH attribute is a well-known 147 mandatory attribute that is composed of a sequence of AS path 148 segments. Each AS path segment is represented by a triple . 151 In [1], the path segment type is a 1-octet long field with the two 152 following values defined: 154 Value Segment Type 156 1 AS_SET: unordered set of ASs a route in the 157 UPDATE message has traversed 159 2 AS_SEQUENCE: ordered set of ASs a route in 160 the UPDATE message has traversed 162 This document reserves two additional segment types: 164 3 AS_CONFED_SEQUENCE: ordered set of Member AS Numbers 165 in the local confederation that the UPDATE message has 166 traversed 168 4 AS_CONFED_SET: unordered set of Member AS Numbers in 169 the local confederation that the UPDATE message has 170 traversed 172 8. Operation 174 A member of a BGP confederation will use its AS Confederation ID in 175 all transactions with peers that are not members of its 176 confederation. This confederation identifier is considered to be the 177 "externally visible" AS number and this number is used in OPEN 178 messages and advertised in the AS_PATH attribute. 180 A member of a BGP confederation will use its Member AS Number in all 181 transactions with peers that are members of the same confederation as 182 the given router. 184 A BGP speaker receiving an AS_PATH attribute containing an autonomous 185 system matching its own confederation shall treat the path in the 186 same fashion as if it had received a path containing its own AS 187 number. 189 A BGP speaker receiving an AS_PATH attribute containing an 190 AS_CONFED_SEQUENCE or AS_CONFED_SET which contains its own Member AS 191 Number shall treat the path in the same fashion as if it had received 192 a path containing its own AS number. 194 8.1. AS_PATH Modification Rules 196 Section 5.1.2 of [1] is replaced with the following text: 198 When a BGP speaker propagates a route which it has learned from 199 another BGP speaker's UPDATE message, it shall modify the route's 200 AS_PATH attribute based on the location of the BGP speaker to which 201 the route will be sent: 203 a) When a given BGP speaker advertises the route to another BGP 204 speaker located in its own autonomous system, the advertising speaker 205 shall not modify the AS_PATH attribute associated with the route. 207 b) When a given BGP speaker advertises the route to a BGP speaker 208 located in a neighboring autonomous system that is a member of the 209 local autonomous system confederation, then the advertising speaker 210 shall update the AS_PATH attribute as follows: 212 1) if the first path segment of the AS_PATH is of type 213 AS_CONFED_SEQUENCE, the local system shall prepend its own AS 214 number as the last element of the sequence (put it in the 215 leftmost position). 217 2) if the first path segment of the AS_PATH is not of type 218 AS_CONFED_SEQUENCE the local system shall prepend a new path 219 segment of type AS_CONFED_SEQUENCE to the AS_PATH, including 220 its own confederation identifier in that segment. 222 c) When a given BGP speaker advertises the route to a BGP speaker 223 located in a neighboring autonomous system that is not a member of 224 the current autonomous system confederation, the advertising speaker 225 shall update the AS_PATH attribute as follows: 227 1) if the first path segment of the AS_PATH is of type 228 AS_CONFED_SEQUENCE, that segment and any immediately following 229 segments of the type AS_CONFED_SET or AS_CONFED_SEQUENCE are 230 removed from the AS_PATH attribute, leaving the sanitized 231 AS_PATH attribute to be operated on by steps 2, or 3. 233 2) if the first path segment of the remaining AS_PATH is of 234 type AS_SEQUENCE, the local system shall prepend its own 235 confederation ID as the last element of the sequence (put it 236 in the leftmost position). 238 3) if there are no path segments following the removal of the 239 first AS_CONFED_SET/AS_CONFED_SEQUENCE segments, or if the 240 first path segment of the remaining AS_PATH is of type AS_SET 241 the local system shall prepend a new path segment of type 242 AS_SEQUENCE to the AS_PATH, including its own confederation 243 ID in that segment. 245 When a BGP speaker originates a route: 247 a) the originating speaker shall include an empty AS_PATH attribute 248 in all UPDATE messages sent to BGP speakers located in its own Member 249 AS Number. (An empty AS_PATH attribute is one whose length field 250 contains the value zero). 252 b) the originating speaker shall include its own Member AS Number in 253 an AS_CONFED_SEQUENCE segment of the AS_PATH attribute of all UPDATE 254 messages sent to BGP speakers located in neighboring Member-AS that 255 are members of the local confederation (i.e., the originating 256 speaker's Member AS Number will be the only entry in the AS_PATH 257 attribute). 259 c) the originating speaker shall include its own autonomous system in 260 an AS_SEQUENCE segment of the AS_PATH attribute of all UPDATE 261 messages sent to BGP speakers located in neighboring autonomous 262 systems that are not members of the local confederation. (In this 263 case, the autonomous system number of the originating speaker's 264 member confederation will be the only entry in the AS_PATH 265 attribute). 267 9. Common Administration Issues 269 It is reasonable for member ASs of a confederation to share a common 270 administration and IGP information for the entire confederation. 272 It shall be legal for a BGP speaker to advertise an unchanged 273 NEXT_HOP and MULTI_EXIT_DISCRIMINATOR (MED) attribute to peers in a 274 neighboring AS within the same confederation. In addition, the 275 restriction against sending the LOCAL_PREFERENCE attribute to peers 276 in a neighboring AS within the same confederation is removed. Path 277 selection criteria for information received from members inside a 278 confederation MUST follow the same rules used for information 279 received from members inside the same autonomous system, as specified 280 in [1]. 282 10. Compatability Considerations 284 All BGP speakers participating in a confederation must recognize the 285 AS_CONFED_SET and AS_CONFED_SEQUENCE segment type extensions to the 286 AS_PATH attribute. 288 Any BGP speaker not supporting these extensions will generate a 289 notification message specifying an "UPDATE Message Error" and a sub- 290 code of "Malformed AS_PATH". 292 This compatibility issue implies that all BGP speakers participating 293 in a confederation MUST support BGP confederations. However, BGP 294 speakers outside the confederation need not support these extensions. 296 11. Deployment Considerations 298 BGP confederations have been widely deployed throughout the Internet 299 for a number of years and are supported by multiple vendors. 301 Improper configuration of BGP confederations can cause routing 302 information within an AS to be duplicated unnecessarily. This 303 duplication of information will waste system resources, cause 304 unnecessary route flaps, and delay convergence. 306 Care should be taken to manually filter duplicate advertisements 307 caused by reachability information being relayed through multiple 308 member autonomous systems based upon the topology and redundancy 309 requirements of the confederation. 311 Additionally, confederations (as well as route reflectors), by 312 excluding different reachability information from consideration at 313 different locations in a confederation, have been shown to cause 314 permanent oscillation between candidate routes when using the tie 315 breaking rules required by BGP[1]. Care must be taken when selecting 316 MED values and tie breaking policy to avoid these situations. 318 One potential way to avoid this is by configuring inter-Member-AS IGP 319 metrics higher than intra-Member-AS IGP metrics and/or using other 320 tie breaking policies to avoid BGP route selection based on 321 incomparable MEDs. 323 12. Security Considerations 325 This extension to BGP does not change the underlying security issues 326 inherent in the existing BGP, such as those defined in [6]. 328 13. Acknowledgments 330 The general concept of BGP confederations was taken from IDRP's 331 Routing Domain Confederations [2]. Some of the introductory text in 332 this document was taken from [5]. 334 The authors would like to acknowledge Bruce Cole of Juniper Networks 335 for his implementation feedback and extensive analysis of the 336 limitations of the protocol extensions described in this document and 337 [5]. We would also like to acknowledge Srihari Ramachandra of Cisco 338 Systems, Inc. for his feedback. 340 Finally, we'd like to acknowledge Ravi Chandra and Yakov Rekhter for 341 providing constructive and valuable feedback on earlier versions of 342 this document. 344 Appendix A, Comparison with RFC 1965 346 The most notable change from [1] is that of reversing the values 347 AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in 348 section "AS_CONFED Segment Type Extension". The reasoning for this 349 is that in the initial implemention, which was already widely 350 deployed, they were implemented backwards from [4], and as such, 351 subsequent implementations implemented them backwards as well. In 352 order to foster interoperability and compliance with deployed 353 implementations, they've therefore been changed here as well. 355 The "Compatibility Discussion" was removed and incorporated into 356 other discussions in the document. Also, the mention of hierarchial 357 confederations is removed. The use of the term "Routing Domain 358 Identifier" was replaced with Member AS Number. 360 Finally, the "Deployment Considerations" section was expanded a few 361 subtle grammar changes were made and a bit more introductory text was 362 added. 364 14. References 366 [1] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 367 RFC 1771, March 1995. 369 [2] Kunzinger, C., Editor, "Inter-Domain Routing Protocol", ISO/IEC 370 10747, October 1993. 372 [3] Haskin, D., "A BGP/IDRP Route Server alternative to a full 373 mesh routing", RFC 1863, October 1995. 375 [4] Traina, P. "Autonomous System Confederations for BGP", RFC 376 1965, June 1996. 378 [5] Bates, T., Chandra, R. and Chen, E., "BGP Route Reflection 379 An Alternative to Full Mesh IBGP", RFC 2796, April 2000. 381 [6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Sig- 382 nature Option", RFC2385, August 1998. 384 15. Authors' Address 386 Paul Traina 387 Juniper Networks, Inc. 388 1194 N. Mathilda Ave. 389 Sunnyvale, CA 94089 USA 390 Phone: +1 408 745-2000 391 Email: pst+confed@juniper.net 393 Danny McPherson 394 Amber Networks, Inc. 395 2465 Augustine Drive 396 Santa Clara, CA 95054 397 Phone: +1 408.486.6336 398 Email: danny@ambernetworks.com 400 John G. Scudder 401 Cisco Systems, Inc. 402 170 West Tasman Drive 403 San Jose, CA 95134 404 Phone: +1 734.669.8800 405 Email: jgs@cisco.com