idnits 2.17.1 draft-ietf-idr-custom-decision-07.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 (November 1, 2015) is 3099 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: May 4, 2016 Ericsson 6 November 1, 2015 8 BGP Custom Decision Process 9 draft-ietf-idr-custom-decision-07 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 May 4, 2016. 46 Copyright Notice 48 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Cost Community Point of Insertion Registry . . . . . . . 7 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 9.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 76 A.1. Changes between the -00 and -01 versions. . . . . . . . . 9 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 The BGP specification defines a Decision Process [RFC4271] for 88 selecting the best route. This process uses a series of steps, made 89 up of path attributes and other values, to first determine the Degree 90 of Preference of a route and later as tie breakers. While existing 91 mechanisms may achieve some of the same results described in this 92 document, they can only do so through extensive configuration such as 93 matching communities to explicit policy and/or route preference 94 configurations present on each BGP speaker within their 95 administrative domain (autonomous system). Implementing some 96 specific fine grained policies through such mechanisms is cumbersome, 97 if even possible. For example: 99 o Local Preference: The LOCAL_PREF is an attribute used to calculate 100 the Degree of Preference in the Decision Process. There is no 101 secondary degree of preference indicator available that can be 102 considered after the MED, IGP metric, or other attributes. 104 o Multi-Exit Discriminator (MED): The MULTI_EXIT_DISC is an 105 indicator of which local entrance point an AS would like a peering 106 AS to use. As the MED is compared before the IGP metric, there is 107 no way to set the MED so a route with a higher IGP metric is 108 preferred over one with a lower IGP metric. 110 o IGP Metric: It is possible, to influence individual routes, but 111 only by changing the next hops, and configuring the IGP metric for 112 reaching them. This method is cumbersome and prone to confusion 113 and error. 115 This document defines a new Extended Community [RFC4360], called the 116 Cost Community, which may be used as part of the Decision Process. 117 The end result is a local Custom Decision Process. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. The BGP Cost Community 127 The BGP Cost Community is an Opaque Extended Community [RFC4360] 128 defined as follows: 130 Type Field: 131 The value of the high-order octet is determined by provisioning 132 [RFC4360]. IANA has assigned the codepoint value 0x01 to 'Cost 133 Community' in both the Transitive Opaque Extended Community Sub- 134 Types registry and the Non-Transitive Opaque Extended Community 135 Sub-Types registry. 137 Value Field: 139 The Value field contains three distinct sub-fields, described 140 below: 142 +------------------------------+ 143 | Point of Insertion (1 octet) | 144 +------------------------------+ 145 | Community-ID (1 octet) | 146 +------------------------------+ 147 | Cost (4 octets) | 148 +------------------------------+ 150 The Point of Insertion (POI) sub-field indicates *after*, or 151 *instead of*, which step in the Decision Process the Cost 152 Community MUST be considered. 154 The value of the POI may reference a path attribute used in the 155 Decision Process. In this case the Cost Community is 156 considered after, or instead of, the step where the path 157 attribute is considered. 159 The Decision Process includes some steps that do not correspond 160 to any path attribute; the following values are defined: 162 128 ABSOLUTE_VALUE - Indicates that the Cost Community MUST be 163 considered as the first step in determining the Degree of 164 Preference of a route (Section 9.1.1 of [RFC4271]). If two 165 routes have the same Cost, then the rest of the Calculation 166 of Degree of Preference is to be followed. 168 129 IGP_COST - Indicates that the Cost Community MUST be 169 considered after the interior (IGP) distance to the next-hop 170 has been compared. 172 130 EXTERNAL_INTERNAL - Indicates that the Cost Community MUST 173 be considered after Paragraph d of Section 9.1.2.2 of 174 [RFC4271]. 176 131 BGP_ID - Indicates that the Cost Community MUST be 177 considered after the BGP Identifier (or ORIGINATOR_ID 178 [RFC4456]) has been compared. 180 This document creates a new Cost Community Point of Insertion 181 Registry (Section 7.1) that includes the relevant path 182 attributes and these other values. 184 The Community-ID sub-field contains an identifier to distinguish 185 between multiple instances of the Cost Community. The high-order 186 bit indicates that the Cost Community MUST replace the step 187 indicated by the POI in the Decision Process. 189 If the high-order bit is set, the Cost in the Cost Community 190 may replace the value of a path attribute at a specific step in 191 the Decision Process, but not the attribute itself. For 192 example, if the high-order bit is set with the AS_PATH POI, the 193 AS_PATH attribute would still be used for loop prevention 194 [RFC4271], but the Cost would replace its length in the 195 Decision Process. 197 The high-order bit MUST be ignored when used with the 198 ABSOLUTE_VALUE POI. 200 If the Accumulated IGP Metric Attribute (AIGP) [RFC7311] is 201 used such that the "AIGP-enhanced interior cost" replaces the 202 "interior cost" tie breaker in the Decision Process, and the 203 high-order bit is set with the IGP_COST POI, then the Cost 204 Community SHOULD be ignored in favor of the process described 205 in Section 4.2 of [RFC7311]. 207 The Cost sub-field is a 32-bit unsigned integer. It contains a 208 value assigned by the network administrator that is significant to 209 their administrative domain. The default Cost is 0x7FFFFFFF (half 210 the maximum). 212 If the Cost Community is inserted after a step in the Decision 213 Process, and is therefore only compared to other Cost 214 Communities, the lower Cost MUST be preferred. 216 If the Cost Community replaces a step in the Decision Process, 217 it MUST be treated exactly as the value it is replacing would 218 be treated. It is up to the network administrator to select 219 the appropriate Cost to use when replacing a specific step; the 220 method to do that is outside the scope of this document. 222 4. Operation 224 The network administrator may use the Cost Community to assign a Cost 225 to a route originated, or learned from a peer, in any part of their 226 administrative domain. The POI MUST also be specified. 228 If a BGP speaker receives a route that contains the Cost Community, 229 it MUST consider its Cost at the POI specified, during the Decision 230 Process. 232 If the POI is not valid for the local Decision Process 233 implementation, then the Cost Community SHOULD be silently ignored. 235 Multiple Cost Communities may indicate the same POI. All the Cost 236 Communities for a specific POI MUST be considered starting with the 237 one(s) with the lowest Community-ID. If multiple Cost Communities, 238 for the same POI, with the same Community-ID are received for the 239 same route from the same peer, then all except the one with the 240 lowest Cost MUST be silently ignored. 242 Routes that do not contain the Cost Community (for a valid, 243 particular POI), or a Community-ID present in a route from another 244 peer, MUST be considered to have the default Cost. 246 If a range of routes is to be aggregated and the resultant aggregate 247 path attributes do not carry the ATOMIC_AGGREGATE attribute, then the 248 resulting aggregate SHOULD have an Extended Communities path 249 attribute which contains the set union of all the Cost Communities 250 from all of the aggregated routes. If multiple Cost Communities for 251 the same POI (and with the same Community-ID) exist, then only the 252 ones with the highest Cost SHOULD be included. 254 If the non-transitive version of a Cost Community is received across 255 an Autonomous System boundary, then the receiver MUST strip it off 256 the BGP update, and ignore it during the Decision Process. 258 5. Deployment Considerations 260 The mechanisms described in this document may be used to modify the 261 Decision Process arbitrarily. It is important that a consistent 262 Decision Process be maintained across the local Autonomous System to 263 avoid potential routing loops. In other words, all the nodes in the 264 AS that may have to consider the Cost Community at any POI MUST 265 support the mechanisms described in this document. 267 Any mechanism which allows the modification of the Decision Process 268 is capable of forming persistent routing loops in the control plane. 269 Network administrators deploying the Cost Community MUST ensure that 270 each impacted router in the network supports them, including the POIs 271 deployed within their network. This is similar in scope to a network 272 administrator who uses communities [RFC1997] combined with filters or 273 other policies to modify the Decision Process of BGP speakers. 274 Consistency must be enforced at an administrative level. 276 6. Security Considerations 278 This document defines a new Extended Community, called the Cost 279 Community, which may be used to customize the Decision Process. As 280 such, the considerations outlined in [RFC4360] and [RFC4271] do not 281 change. 283 To minimize the potential of creating routing loops (Section 5) or 284 otherwise affecting the Decision Process in unintended ways, the 285 propagation of Cost Communities MUST be disabled by default and MUST 286 be explicitly enabled by the network administrator. Furthermore, all 287 transitive Cost Communities received across an Autonomous System 288 boundary without explicit configuration MUST be stripped off the BGP 289 update, and ignored during the Decision Process. 291 An ill-designed policy deployment using the Cost Community (e.g. one 292 where there is no consistent POI support throughout the AS) may 293 result in persistent routing loops that could result in loss of 294 traffic. The design and implementation of policies for best route 295 selection are outside the scope of this document. 297 7. IANA Considerations 299 IANA has assigned the codepoint value 0x01 to 'Cost Community' in 300 both the Transitive Opaque Extended Community Sub-Types registry and 301 the Non-Transitive Opaque Extended Community Sub-Types registry. 303 Section 3 also defines a series of values to be used to indicate 304 steps in the Decision Process that do not map directly to a path 305 attribute. IANA is expected to maintain a registry for the Cost 306 Community POI values. 308 o Values 1 through 127 are to be assigned using the "Standards 309 Action" policy or the Early Allocation process [RFC7120]. 311 o Values 128 through 191 are to be assigned using the "IETF 312 Consensus" policy. 314 o Values 192 through 254 are to be assigned using the "First Come 315 First Served" policy. 317 o Values 0 and 255 are reserved. 319 All the policies mentioned are documented in [RFC5226]. 321 The table in Section 7.1 shows the initial allocations for the new 322 Cost Community Point of Insertion registry. 324 7.1. Cost Community Point of Insertion Registry 326 The tables below document the initial Cost Community Point of 327 Insertion Registry 328 +---------+-------------------------+ 329 | Range | Registration Procedure | 330 +---------+-------------------------+ 331 | 0 | Reserved | 332 | 1-127 | Standards Action | 333 | 128-191 | IETF Consensus | 334 | 192-254 | First Come First Served | 335 | 255 | Reserved | 336 +---------+-------------------------+ 338 Registration Procedure 340 +--------+-------------------+--------------------------------+ 341 | Value | Code | Reference | 342 +--------+-------------------+--------------------------------+ 343 | 1 | ORIGIN | RFC4271 | 344 | 2 | AS_PATH | RFC4271 | 345 | 3 | Unassigned | | 346 | 4 | MULTI_EXIT_DISC | RFC4271 | 347 | 5 | LOCAL_PREF | RFC4271 | 348 | 6-25 | Unassigned | | 349 | 26 | AIGP | RFC7311 | 350 | 27-127 | Unassigned | | 351 | 128 | ABSOLUTE_VALUE | draft-ietf-idr-custom-decision | 352 | 129 | IGP_COST | draft-ietf-idr-custom-decision | 353 | 130 | EXTERNAL_INTERNAL | draft-ietf-idr-custom-decision | 354 | 131 | BGP_ID | draft-ietf-idr-custom-decision | 355 +--------+-------------------+--------------------------------+ 357 Point of Insertion 359 8. Acknowledgements 361 There have been many people who have shown their support and provided 362 valuable input, comments and implementations -- the authors would 363 like to thank all of them! We would like to also thank Dan Tappan 364 for the Opaque Extended Community type. Bruno Decraene and Eric 365 Rosen thoroughly reviewed this document and helped improved its 366 quality significantly. 368 9. References 370 9.1. Normative References 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, 374 DOI 10.17487/RFC2119, March 1997, 375 . 377 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 378 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 379 DOI 10.17487/RFC4271, January 2006, 380 . 382 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 383 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 384 February 2006, . 386 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 387 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 388 DOI 10.17487/RFC5226, May 2008, 389 . 391 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 392 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 393 2014, . 395 [RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, 396 "The Accumulated IGP Metric Attribute for BGP", RFC 7311, 397 DOI 10.17487/RFC7311, August 2014, 398 . 400 9.2. Informative References 402 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 403 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 404 . 406 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 407 Reflection: An Alternative to Full Mesh Internal BGP 408 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 409 . 411 Appendix A. Change Log 413 This section is to be removed before publication. 415 A.1. Changes between the -00 and -01 versions. 417 o Updated authors' contact information. 419 o Editorial changes in the "Operations" and "Acknowledgement" 420 sections. 422 A.2. Changes between the -01 and -02 versions. 424 o Updated authors' contact information. 426 o Added text to replace a step in the selection process. 428 o Minor edits. 430 A.3. Changes between the -02 and -03 versions. 432 o No changes; just a refresh. 434 A.4. Changes between the -03 and -04 versions. 436 o Updated authors' contact information. 438 A.5. Changes between the -04 and -05 versions. 440 o Updated authors' contact information. 442 A.6. Changes between the -05 and -06 versions. 444 o Updated RFC 7120 reference (from RFC 4020). 446 A.7. Changes between the -06 and -07 versions 448 o The review from Bruno Decraene and Eric Rosen resulted in several 449 important changes related to the clarity and consistency of the 450 document. 452 o Added considerations for co-existence with AIGP. 454 o Security Considerations. 456 Authors' Addresses 458 Alvaro Retana 459 Cisco Systems, Inc. 460 7025 Kit Creek Rd. 461 Research Triangle Park, NC 27709 462 USA 464 Email: aretana@cisco.com 465 Russ White 466 Ericsson 467 Apex, NC 27539 468 USA 470 Email: russw@riw.us