idnits 2.17.1 draft-ietf-idr-custom-decision-05.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 (October 22, 2014) is 3467 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 4020 (Obsoleted by RFC 7120) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 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: April 25, 2015 Ericsson 6 October 22, 2014 8 BGP Custom Decision Process 9 draft-ietf-idr-custom-decision-05 11 Abstract 13 The BGP specification defines a Decision Process for installation of 14 routes into the Loc-RIB. This process takes into account an 15 extensive series of path attributes, which can be manipulated to 16 indicate preference for specific paths. It is cumbersome (if at all 17 possible) for the end user to define policies that will select, after 18 partial comparison, a path based on subjective local (domain and/or 19 node) criteria. 21 This document defines a new Extended Community, called the Cost 22 Community, which may be used in tie breaking during the best path 23 selection process. The end result is a local custom decision 24 process. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 25, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. The BGP Cost Community . . . . . . . . . . . . . . . . . . . 3 63 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 9.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Appendix A. Cost Community Point of Insertion Registry . . . . . 7 72 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 8 73 B.1. Changes between the -00 and -01 versions. . . . . . . . . 8 74 B.2. Changes between the -01 and -02 versions. . . . . . . . . 8 75 B.3. Changes between the -02 and -03 versions. . . . . . . . . 8 76 B.4. Changes between the -03 and -04 versions. . . . . . . . . 8 77 B.5. Changes between the -04 and -05 versions. . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 There are a number of metrics available within the BGP decision 83 process [RFC4271] which can be used to determine the exit point for 84 traffic, but there is no metric, or combination of metrics, which can 85 be used to break a tie among generally equal paths. 87 o LOCAL_PREF: The LOCAL_PREF is an absolute tie breaker near the 88 beginning of the decision process. There is no way to configure 89 the LOCAL_PREF such that the MED, IGP metric, and other metrics 90 are considered before breaking a tie. 92 o MED: The MULTI_EXIT_DISC is an indicator of which local entrance 93 point an AS would like a peering AS to use; MED isn't suitable to 94 break the tie between two equal cost paths learned from two peer 95 ASes. MED is also compared before the IGP metric; there is no way 96 to set the MED so a path with a higher IGP metric is preferred 97 over a path with a lower IGP metric. 99 o IGP Metric: It is possible, using the IGP metric, to influence 100 individual paths with otherwise equal cost metrics, but only by 101 changing the next hop towards each path, and configuring the IGP 102 costs of reaching each next hop. This method is cumbersome, and 103 prone to confusion and error. 105 The BGP specification defines a Decision Process for installation of 106 routes into the Loc-RIB. This process takes into account an 107 extensive series of path attributes, which can be manipulated to 108 indicate preference for specific paths. It is cumbersome (if at all 109 possible) for the end user to define policies that will select, after 110 partial comparison, a path based on subjective local (domain and/or 111 node) criteria. 113 This document defines a new Extended Community, called the Cost 114 Community, which may be used in tie breaking during the best path 115 selection process. The end result is a custom decision process. 117 2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. The BGP Cost Community 125 The BGP Cost Community is an Opaque Extended Community [RFC4360] 126 defined as follows: 128 Type Field: 129 The value of the high-order octet of this Opaque Extended 130 Community is 0x03 or 0x43. The value of the low-order octet of 131 the extended type field for this community is 0x01. 133 Value Field: 134 The Value field contains three distinct sub-fields, described 135 below: 137 +------------------------------+ 138 | Point of Insertion (1 octet) | 139 +------------------------------+ 140 | Community-ID (1 octet) | 141 +------------------------------+ 142 | Cost (4 octets) | 143 +------------------------------+ 145 The Point of Insertion sub-field contains the value of the path 146 attribute *after* which this community MUST be considered during 147 the best path selection process. 149 The BGP decision process includes some steps that do not 150 correspond to any path attribute; the following values are 151 defined: 153 128 ABSOLUTE_VALUE - Indicates that the Cost Community MUST be 154 considered as the first step in determining the Degree of 155 Preference of a path. 157 129 IGP_COST - Indicates that the Cost Community MUST be 158 considered after the interior (IGP) distance to the next-hop 159 has been compared. 161 130 EXTERNAL_INTERNAL - Indicates that the Cost Community MUST 162 be considered after the paths advertised by BGP speakers in 163 a neighboring autonomous system (if any) have been selected. 165 131 BGP_ID - Indicates that the Cost Community MUST be 166 considered after the BGP Identifier (or ORIGINATOR_ID 167 [RFC4456]) has been compared. 169 The Community-ID sub-field contains an identifier to distinguish 170 between multiple instances of the Cost Community. The high-order 171 bit is reserved to indicate that the Cost Community MUST replace 172 the path attribute specified by the Point of Insertion during the 173 best path selection process. 175 The Cost sub-field contains a value assigned by the network 176 administrator and that is significant to the local autonomous 177 system. The lower cost MUST be preferred. The default value is 178 0x7FFFFFFF (half the maximum value). 180 4. Operation 182 The network administrator may use the Cost Community to assign a 183 value to a path originated or learned from a peer in any part of the 184 local domain. The Point of Insertion MUST also be specified using 185 the values defined in Appendix A. 187 If a BGP speaker receives a path that contains the Cost Community, it 188 SHOULD consider its value at the Point of Insertion specified, when 189 calculating the best path [RFC4271]. 191 If the Point of Insertion is not valid for the local best path 192 selection implementation, then the Cost Community SHOULD be silently 193 ignored. Paths that do not contain the Cost Community (for a valid, 194 particular Point of Insertion) MUST be considered to have the default 195 value. 197 Multiple Cost Communities may indicate the same Point of Insertion. 198 In this case, the Cost Community with the lowest Community-ID is 199 considered first. In other words, all the Cost Communities for a 200 specific Point of Insertion MUST be considered, starting with the one 201 with the lowest Community-ID. 203 If a range of routes is to be aggregated and the resultant aggregate 204 path attributes do not carry the ATOMIC_AGGREGATE attribute, then the 205 resulting aggregate SHOULD have an Extended Communities path 206 attribute which contains the set union of all the Cost Communities 207 from all of the aggregated routes. If multiple Cost Communities for 208 the same Point of Insertion (and with the same Community-ID) exist, 209 then only the ones with the highest Cost SHOULD be included. 211 If the non-transitive version of a Cost Community is received across 212 an Autonomous System boundary, then the receiver MUST strip it off 213 the BGP update, and ignore it when running the selection process. 215 5. Deployment Considerations 217 The mechanisms described in this document may be used to modify the 218 BGP path selection process arbitrarily. It is important that a 219 consistent path selection process be maintained across the local 220 Autonomous System to avoid potential routing loops. In other words, 221 if the Cost Community is used, all the nodes in the AS that may have 222 to consider this new community at any Point of Insertion SHOULD be 223 aware of the mechanisms described in this document. 225 6. Security Considerations 227 This document introduces no new security concerns to BGP or other 228 specifications referenced in this document. 230 7. IANA Considerations 232 IANA is asked to assign the type values indicated in Section 3 to the 233 Cost Community in the BGP Opaque Extended Community registry 234 [BGP_EXT]. 236 Section 3 also defines a series of values to be used to indicate 237 steps in the best path selection process that do not map directly to 238 a path attribute. IANA is expected to maintain a registry for the 239 Cost Community Point of Insertion values. Values 1 through 127 are 240 to be assigned using the "Standards Action" policy or the Early 241 Allocation process [RFC4020]. Values 128 through 191 are to be 242 assigned using the "IETF Consensus" policy. Values 192 through 254 243 are to be assigned using the "First Come First Served" policy. 244 Values 0 and 255 are reserved for future use and SHOULD NOT be used. 245 All the policies mentioned are documented in [RFC5226]. 247 Some of the values in this new registry match the values assigned in 248 the BGP Path Attributes registry [BGP_PAR]. It is RECOMMENDED that 249 an effort be made to assign the same values in both tables when 250 applicable. The table in Appendix A shows the initial allocations 251 for the new Cost Community Point of Insertion registry. 253 8. Acknowledgements 255 There have been many people who have shown their support and provided 256 valuable input, comments and implementations -- the authors would 257 like to thank all of them! We would like to also thank Dan Tappan 258 for the Opaque Extended Community type. 260 9. References 262 9.1. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 268 Standards Track Code Points", RFC 4020, February 2005. 270 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 271 Communities Attribute", RFC 4360, February 2006. 273 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 274 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 275 May 2008. 277 9.2. Informative References 279 [BGP_EXT] Internet Assigned Numbers Authority, "BGP Extended 280 Communities", 2010, . 283 [BGP_PAR] Internet Assigned Numbers Authority, "BGP Parameters", 284 2010, . 286 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 287 Protocol 4 (BGP-4)", RFC 4271, January 2006. 289 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 290 Reflection: An Alternative to Full Mesh Internal BGP 291 (IBGP)", RFC 4456, April 2006. 293 Appendix A. Cost Community Point of Insertion Registry 295 The tables below document the initial Cost Community Point of 296 Insertion Registry 298 +---------+-------------------------+ 299 | Range | Registration Procedure | 300 +---------+-------------------------+ 301 | 0 | Reserved | 302 | 1-127 | Standards Action | 303 | 128-191 | IETF Consensus | 304 | 192-254 | First Come First Served | 305 | 255 | Reserved | 306 +---------+-------------------------+ 308 Registration Procedure 310 +--------+-------------------+--------------------------------+ 311 | Value | Code | Reference | 312 +--------+-------------------+--------------------------------+ 313 | 1 | ORIGIN | RFC4271 | 314 | 2 | AS_PATH | RFC4271 | 315 | 3 | Unassigned | | 316 | 4 | MULTI_EXIT_DISC | RFC4271 | 317 | 5 | LOCAL_PREF | RFC4271 | 318 | 6-25 | Unassigned | | 319 | 26 | AIGP | draft-ietf-idr-aigp | 320 | 27-127 | Unassigned | | 321 | 128 | ABSOLUTE_VALUE | draft-ietf-idr-custom-decision | 322 | 129 | IGP_COST | draft-ietf-idr-custom-decision | 323 | 130 | EXTERNAL_INTERNAL | draft-ietf-idr-custom-decision | 324 | 131 | BGP_ID | draft-ietf-idr-custom-decision | 325 +--------+-------------------+--------------------------------+ 327 Point of Insertion Codes 329 Appendix B. Change Log 331 B.1. Changes between the -00 and -01 versions. 333 o Updated authors' contact information. 335 o Editorial changes in the "Operations" and "Acknowledgement" 336 sections. 338 B.2. Changes between the -01 and -02 versions. 340 o Updated authors' contact information. 342 o Added text to replace a step in the selection process. 344 o Minor edits. 346 B.3. Changes between the -02 and -03 versions. 348 o No changes; just a refresh. 350 B.4. Changes between the -03 and -04 versions. 352 o Updated authors' contact information. 354 B.5. Changes between the -04 and -05 versions. 356 o Updated authors' contact information. 358 Authors' Addresses 360 Alvaro Retana 361 Cisco Systems, Inc. 362 7025 Kit Creek Rd. 363 Research Triangle Park, NC 27709 364 USA 366 Email: aretana@cisco.com 368 Russ White 369 Ericsson 371 Email: russw@riw.us