idnits 2.17.1 draft-ietf-idr-custom-decision-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 3, 2017) is 2638 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 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing A. Retana 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track R. White 5 Expires: August 7, 2017 LinkedIn 6 February 3, 2017 8 BGP Custom Decision Process 9 draft-ietf-idr-custom-decision-08 11 Abstract 13 The BGP specification describes a Decision Process for selecting the 14 best route. This process uses a series of steps, made up of path 15 attributes and other values, to first determine the Degree of 16 Preference of a route and later as tie breakers. While existing 17 mechanisms may achieve some of the same results described in this 18 document, they can only do so through extensive configuration such as 19 matching communities to explicit policy and/or route preference 20 configurations present on each BGP speaker within their 21 administrative domain (autonomous system). Implementing some 22 specific fine grained policies through such mechanisms is cumbersome, 23 if even possible. 25 This document defines a new Extended Community, called the Cost 26 Community, which may be used as part of the Decision Process. The 27 end result is a local Custom Decision Process. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 7, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 65 3. The BGP Cost Community . . . . . . . . . . . . . . . . . . . 3 66 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Cost Community Point of Insertion Registry . . . . . . . 8 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 9.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 76 A.1. Changes between the -00 and -01 versions. . . . . . . . . 10 77 A.2. Changes between the -01 and -02 versions. . . . . . . . . 10 78 A.3. Changes between the -02 and -03 versions. . . . . . . . . 10 79 A.4. Changes between the -03 and -04 versions. . . . . . . . . 10 80 A.5. Changes between the -04 and -05 versions. . . . . . . . . 10 81 A.6. Changes between the -05 and -06 versions. . . . . . . . . 10 82 A.7. Changes between the -06 and -07 versions . . . . . . . . 10 83 A.8. Changes between the -07 and -08 versions . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 The BGP specification defines a Decision Process [RFC4271] for 89 selecting the best route. This process uses a series of steps, made 90 up of path attributes and other values, to first determine the Degree 91 of Preference of a route and later as tie breakers. While existing 92 mechanisms may achieve some of the same results described in this 93 document, they can only do so through extensive configuration such as 94 matching communities to explicit policy and/or route preference 95 configurations present on each BGP speaker within their 96 administrative domain (autonomous system). Implementing some 97 specific fine grained policies through such mechanisms is cumbersome, 98 if even possible. For example: 100 o Local Preference: The LOCAL_PREF is an attribute used to calculate 101 the Degree of Preference in the Decision Process. There is no 102 secondary degree of preference indicator available that can be 103 considered after the MED, IGP metric, or other attributes. 105 o Multi-Exit Discriminator (MED): The MULTI_EXIT_DISC is an 106 indicator of which local entrance point an AS would like a peering 107 AS to use. As the MED is compared before the IGP metric, there is 108 no way to set the MED so a route with a higher IGP metric is 109 preferred over one with a lower IGP metric. 111 o IGP Metric: It is possible, to influence individual routes, but 112 only by changing the next hops, and configuring the IGP metric for 113 reaching them. This method is cumbersome and prone to confusion 114 and error. 116 This document defines a new Extended Community [RFC4360], called the 117 Cost Community, which may be used as part of the Decision Process. 118 The end result is a local Custom Decision Process. 120 2. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. The BGP Cost Community 128 The BGP Cost Community is an Opaque Extended Community [RFC4360] 129 defined as follows: 131 Type Field: 132 The value of the high-order octet is determined by provisioning 133 [RFC4360]. IANA has assigned the codepoint value 0x01 to 'Cost 134 Community' in both the Transitive Opaque Extended Community Sub- 135 Types registry and the Non-Transitive Opaque Extended Community 136 Sub-Types registry. 138 Value Field: 140 The Value field contains four distinct sub-fields, described 141 below: 143 0 1 2 3 4 5 6 7 144 +--------------------------------------+ 145 | Point of Insertion (1 octet) | 146 +--------------------------------------+ 147 | R | Community-ID (7 bits) | 148 +--------------------------------------+ 149 | Cost (4 octets) | 150 | | 151 | | 152 | | 153 +--------------------------------------+ 155 The Point of Insertion (POI) sub-field indicates *after*, or 156 *instead of*, which step in the Decision Process the Cost 157 Community MUST be considered. The Point of Application (POA) 158 refers to the step in the Decision Process where the Cost 159 Community is effectively considered -- the relationship between 160 the POI and the POA is determined by the Replace Bit (see below). 162 The value of the POI may reference a path attribute used in the 163 Decision Process. In this case the POA is related to the step 164 where the path attribute is considered. 166 The Decision Process includes some steps that do not correspond 167 to any path attribute; the following values are defined: 169 128 ABSOLUTE_VALUE - Indicates that the Cost Community MUST be 170 considered as the first step in determining the Degree of 171 Preference of a route (Section 9.1.1 of [RFC4271]). If two 172 routes have the same Cost, then the rest of the Calculation 173 of Degree of Preference is to be followed. 175 129 IGP_COST - Indicates that the Cost Community MUST be 176 considered after the interior (IGP) distance to the next-hop 177 has been compared. 179 130 EXTERNAL_INTERNAL - Indicates that the Cost Community MUST 180 be considered after Paragraph d of Section 9.1.2.2 of 181 [RFC4271]. 183 131 BGP_ID - Indicates that the Cost Community MUST be 184 considered after the BGP Identifier (or ORIGINATOR_ID 185 [RFC4456]) has been compared. 187 This document creates a new Cost Community Point of Insertion 188 Registry (Section 7.1) that includes the relevant path 189 attributes and these other values. 191 The Replace Bit (R-bit) is a single-bit field, that when set 192 indicates that the Cost Community MUST replace the step indicated 193 by the POI in the Decision Process. 195 If the R-bit is not set, then the POA is after the step in the 196 Decision Process indicated by the POI, which may result in an 197 additional step. If the R-bit is set, then the POA is at the 198 step identified by the POI. 200 If the R-bit is set, the Cost in the Cost Community replaces 201 the value of a path attribute at a specific step in the 202 Decision Process, but not the attribute itself. For example, 203 if the R-bit is set with the AS_PATH POI, the AS_PATH attribute 204 would still be used for loop detection [RFC4271], but the Cost 205 would replace its length in the Decision Process. 207 The R-bit MUST be ignored when used with the ABSOLUTE_VALUE 208 POI. 210 If the Accumulated IGP Metric Attribute (AIGP) [RFC7311] is 211 used such that the "AIGP-enhanced interior cost" replaces the 212 "interior cost" tie breaker in the Decision Process, and the 213 R-bit is set with the IGP_COST POI, then the Cost Community 214 SHOULD be ignored in favor of the process described in 215 Section 4.2 of [RFC7311]. 217 The Community-ID sub-field contains an identifier to distinguish 218 between multiple instances of the Cost Community. 220 The Cost sub-field is a 32-bit unsigned integer. It contains a 221 value assigned by the network administrator that is significant to 222 their administrative domain. The default Cost is 0x7FFFFFFF (half 223 the maximum). 225 If the Cost Community is inserted after a step in the Decision 226 Process, and is therefore only compared to other Cost 227 Communities, the lower Cost MUST be preferred. 229 If the Cost Community replaces a step in the Decision Process, 230 it MUST be treated exactly as the value it is replacing would 231 be treated. It is up to the network administrator to select 232 the appropriate Cost to use when replacing a specific step; the 233 method to do that is outside the scope of this document. 235 4. Operation 237 The network administrator may use the Cost Community to assign a Cost 238 to a route originated, or learned from a peer, in any part of their 239 administrative domain. The POA MUST also be specified by the 240 combination of the POI and the R-bit. 242 If a BGP speaker receives a route that contains the Cost Community, 243 it MUST consider its Cost at the POA specified, during the Decision 244 Process. 246 If the POI is not valid for the local Decision Process 247 implementation, then the Cost Community SHOULD be silently ignored. 249 Multiple Cost Communities may indicate the same POA. All the Cost 250 Communities for a specific POA MUST be considered starting with the 251 one(s) with the lowest Community-ID. If multiple Cost Communities, 252 for the same POA, with the same Community-ID are received for the 253 same route from the same peer, then all except the one with the 254 lowest Cost MUST be silently ignored. 256 Routes that do not contain the Cost Community (for a valid, 257 particular POA), or a Community-ID present in a route from another 258 peer, MUST be considered to have the default Cost. 260 If a range of routes is to be aggregated and the resultant aggregate 261 path attributes do not carry the ATOMIC_AGGREGATE attribute, then the 262 resulting aggregate SHOULD have an Extended Communities path 263 attribute which contains the set union of all the Cost Communities 264 from all of the aggregated routes. If multiple Cost Communities for 265 the same POA (and with the same Community-ID) exist, then only the 266 ones with the highest Cost SHOULD be included. 268 If the non-transitive version of a Cost Community is received across 269 an Autonomous System boundary, then the receiver MUST strip it off 270 the BGP update, and ignore it during the Decision Process. 272 5. Deployment Considerations 274 The mechanisms described in this document may be used to modify the 275 Decision Process arbitrarily. It is important that a consistent 276 Decision Process be maintained across the local Autonomous System to 277 avoid potential routing loops. In other words, all the nodes in the 278 AS that may have to consider the Cost Community MUST support the 279 mechanisms described in this document. 281 Any mechanism which allows the modification of the Decision Process 282 is capable of forming persistent routing loops in the control plane. 284 Network administrators deploying the Cost Community MUST ensure that 285 each impacted router supports them mechanisms in this document for 286 the POIs deployed within their network. This is similar in scope to 287 a network administrator who uses communities [RFC1997] combined with 288 filters or other policies to modify the Decision Process of BGP 289 speakers. Consistency must be enforced at an administrative level. 291 6. Security Considerations 293 This document defines a new Extended Community, called the Cost 294 Community, which may be used to customize the Decision Process. As 295 such, the considerations outlined in [RFC4360] and [RFC4271] do not 296 change. 298 To minimize the potential of creating routing loops (Section 5) or 299 otherwise affecting the Decision Process in unintended ways, the 300 propagation of Cost Communities MUST be disabled by default and MUST 301 be explicitly enabled by the network administrator. Furthermore, all 302 Cost Communities received across an Autonomous System boundary 303 without explicitly being enabled MUST be stripped off the BGP update, 304 and ignored during the Decision Process. 306 An ill-designed policy deployment using the Cost Community (e.g. one 307 where there is no consistent POI support throughout the AS) may 308 result in persistent routing loops that could result in loss of 309 traffic. The design and implementation of policies for best route 310 selection are outside the scope of this document. 312 7. IANA Considerations 314 IANA has assigned the codepoint value 0x01 to 'Cost Community' in 315 both the Transitive Opaque Extended Community Sub-Types registry and 316 the Non-Transitive Opaque Extended Community Sub-Types registry. 318 Section 3 also defines a series of values to be used to indicate 319 steps in the Decision Process that do not map directly to a path 320 attribute. IANA is expected to maintain a registry for the Cost 321 Community POI values. 323 o Values 1 through 127 are to be assigned using the "Standards 324 Action" policy or the Early Allocation process [RFC7120]. 326 o Values 128 through 191 are to be assigned using the "IETF 327 Consensus" policy. 329 o Values 192 through 254 are to be assigned using the "First Come 330 First Served" policy. 332 o Values 0 and 255 are reserved. 334 All the policies mentioned are documented in [RFC5226]. 336 The table in Section 7.1 shows the initial allocations for the new 337 Cost Community Point of Insertion registry. 339 7.1. Cost Community Point of Insertion Registry 341 The tables below document the initial Cost Community Point of 342 Insertion Registry 344 +---------+-------------------------+ 345 | Range | Registration Procedure | 346 +---------+-------------------------+ 347 | 0 | Reserved | 348 | 1-127 | Standards Action | 349 | 128-191 | IETF Consensus | 350 | 192-254 | First Come First Served | 351 | 255 | Reserved | 352 +---------+-------------------------+ 354 Registration Procedure 356 +--------+-------------------+--------------------------------+ 357 | Value | Code | Reference | 358 +--------+-------------------+--------------------------------+ 359 | 1 | ORIGIN | RFC4271 | 360 | 2 | AS_PATH | RFC4271 | 361 | 3 | Unassigned | | 362 | 4 | MULTI_EXIT_DISC | RFC4271 | 363 | 5 | LOCAL_PREF | RFC4271 | 364 | 6-25 | Unassigned | | 365 | 26 | AIGP | RFC7311 | 366 | 27-127 | Unassigned | | 367 | 128 | ABSOLUTE_VALUE | draft-ietf-idr-custom-decision | 368 | 129 | IGP_COST | draft-ietf-idr-custom-decision | 369 | 130 | EXTERNAL_INTERNAL | draft-ietf-idr-custom-decision | 370 | 131 | BGP_ID | draft-ietf-idr-custom-decision | 371 +--------+-------------------+--------------------------------+ 373 Point of Insertion 375 8. Acknowledgements 377 There have been many people who have shown their support and provided 378 valuable input, comments and implementations -- the authors would 379 like to thank all of them! We would like to also thank Dan Tappan 380 for the Opaque Extended Community type. Bruno Decraene and Eric 381 Rosen thoroughly reviewed this document and helped improved its 382 quality significantly. 384 9. References 386 9.1. Normative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, 390 DOI 10.17487/RFC2119, March 1997, 391 . 393 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 394 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 395 DOI 10.17487/RFC4271, January 2006, 396 . 398 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 399 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 400 February 2006, . 402 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 403 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 404 DOI 10.17487/RFC5226, May 2008, 405 . 407 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 408 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 409 2014, . 411 [RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, 412 "The Accumulated IGP Metric Attribute for BGP", RFC 7311, 413 DOI 10.17487/RFC7311, August 2014, 414 . 416 9.2. Informative References 418 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 419 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 420 . 422 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 423 Reflection: An Alternative to Full Mesh Internal BGP 424 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 425 . 427 Appendix A. Change Log 429 This section is to be removed before publication. 431 A.1. Changes between the -00 and -01 versions. 433 o Updated authors' contact information. 435 o Editorial changes in the "Operations" and "Acknowledgement" 436 sections. 438 A.2. Changes between the -01 and -02 versions. 440 o Updated authors' contact information. 442 o Added text to replace a step in the selection process. 444 o Minor edits. 446 A.3. Changes between the -02 and -03 versions. 448 o No changes; just a refresh. 450 A.4. Changes between the -03 and -04 versions. 452 o Updated authors' contact information. 454 A.5. Changes between the -04 and -05 versions. 456 o Updated authors' contact information. 458 A.6. Changes between the -05 and -06 versions. 460 o Updated RFC 7120 reference (from RFC 4020). 462 A.7. Changes between the -06 and -07 versions 464 o The review from Bruno Decraene and Eric Rosen resulted in several 465 important changes related to the clarity and consistency of the 466 document. 468 o Added considerations for co-existence with AIGP. 470 o Security Considerations. 472 A.8. Changes between the -07 and -08 versions 474 o Clarified the Security Considerations to ensure that routers don't 475 apply the Cost Community by default. 477 o Separated the high-order bit in the Community-ID into its oen 478 field (for clarity). Called it the Replace Bit (R-bit). 480 o Introduced the POA concept. 482 Authors' Addresses 484 Alvaro Retana 485 Cisco Systems, Inc. 486 7025 Kit Creek Rd. 487 Research Triangle Park, NC 27709 488 USA 490 Email: aretana@cisco.com 492 Russ White 493 LinkedIn 494 Apex, NC 27539 495 USA 497 Email: russ@riw.us