idnits 2.17.1 draft-ietf-idr-aigp-18.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 (April 28, 2014) is 3613 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) == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-09 == Outdated reference: A later version (-19) exists of draft-ietf-idr-error-handling-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Pradosh Mohapatra 3 Internet Draft Cumulus Networks 4 Intended Status: Proposed Standard 5 Expires: October 28, 2014 Rex Fernando 6 Eric C. Rosen 7 Cisco Systems, Inc. 9 James Uttaro 10 ATT 12 April 28, 2014 14 The Accumulated IGP Metric Attribute for BGP 16 draft-ietf-idr-aigp-18.txt 18 Abstract 20 Routing protocols that have been designed to run within a single 21 administrative domain ("IGPs") generally do so by assigning a metric 22 to each link, and then choosing as the installed path between two 23 nodes the path for which the total distance (sum of the metric of 24 each link along the path) is minimized. BGP, designed to provide 25 routing over a large number of independent administrative domains 26 ("autonomous systems"), does not make its path selection decisions 27 through the use of a metric. It is generally recognized that any 28 attempt to do so would incur significant scalability problems, as 29 well as inter-administration coordination problems. However, there 30 are deployments in which a single administration runs several 31 contiguous BGP networks. In such cases, it can be desirable, within 32 that single administrative domain, for BGP to select paths based on a 33 metric, just as an IGP would do. The purpose of this document is to 34 provide a specification for doing so. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt. 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 Copyright and License Notice 59 Copyright (c) 2014 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1 Specification of requirements ......................... 3 75 2 Introduction .......................................... 3 76 3 AIGP Attribute ........................................ 5 77 3.1 Applicability Restrictions and Cautions ............... 6 78 3.2 Handling a Malformed AIGP Attribute ................... 6 79 3.3 Restrictions on Sending/Receiving ..................... 7 80 3.4 Creating and Modifying the AIGP Attribute ............. 7 81 3.4.1 Originating the AIGP Attribute ........................ 7 82 3.4.2 Modifications by the Originator ....................... 9 83 3.4.3 Modifications by a Non-Originator ..................... 9 84 4 Decision Process ...................................... 11 85 4.1 When a Route has an AIGP Attribute .................... 11 86 4.2 When the Route to the Next Hop has an AIGP attribute .. 12 87 5 Deployment Considerations ............................. 13 88 6 IANA Considerations ................................... 14 89 7 Security Considerations ............................... 14 90 8 Acknowledgments ....................................... 14 91 9 Authors' Addresses .................................... 14 92 10 Normative References .................................. 15 93 11 Informative References ................................ 15 95 1. Specification of requirements 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Introduction 103 There are many routing protocols that have been designed to run 104 within a single administrative domain. These are known collectively 105 as "Interior Gateway Protocols" (IGPs). Typically, each link is 106 assigned a particular "metric" value. The path between two nodes can 107 then be assigned a "distance", which is the sum of the metrics of all 108 the links that belong to that path. An IGP selects the "shortest" 109 (minimal distance) path between any two nodes, perhaps subject to the 110 constraint that if the IGP provides multiple "areas", it may prefer 111 the shortest path within an area to a path that traverses more than 112 one area. Typically the administration of the network has some 113 routing policy which can be approximated by selecting shortest paths 114 in this way. 116 BGP, as distinguished from the IGPs, was designed to run over an 117 arbitrarily large number of administrative domains ("autonomous 118 systems", or "ASes") with limited coordination among the various 119 administrations. BGP does not make its path selection decisions 120 based on a metric; there is no such thing as an "inter-AS metric". 121 There are two fundamental reasons for this: 123 - The distance between two nodes in a common administrative domain 124 may change at any time due to events occurring in that domain. 125 These changes are not propagated around the Internet unless they 126 actually cause the border routers of the domain to select routes 127 with different BGP attributes for some set of address prefixes. 128 This accords with a fundamental principle of scaling, viz., that 129 changes with only local significance must not have global 130 effects. If local changes in distance were always propagated 131 around the Internet, this principle would be violated. 133 - A basic principle of inter-domain routing is that the different 134 administrative domains may have their own policies, which do not 135 have to be revealed to other domains, and which certainly do not 136 have to be agreed to by other domains. Yet the use of inter-AS 137 metric in the Internet would have exactly these effects. 139 There are, however, deployments in which a single administration runs 140 a network which has been sub-divided into multiple, contiguous ASes, 141 each running BGP. There are several reasons why a single 142 administrative domain may be broken into several ASes (which, in this 143 case, are not really "autonomous".) It may be that the existing IGPs 144 do not scale well in the particular environment; it may be that a 145 more generalized topology is desired than could be obtained by use of 146 a single IGP domain; it may be that a more finely grained routing 147 policy is desired than can be supported by an IGP. In such 148 deployments, it can be useful to allow BGP to make its routing 149 decisions based on the IGP metric, so that BGP chooses the "shortest" 150 path between two nodes, even if the nodes are in two different ASes 151 within that same administrative domain. 153 There are in fact some implementations that already do something like 154 this, using BGP's MULTI_EXIT_DISC (MED) attribute to carry a value 155 based on IGP metrics. However, that doesn't really provide IGP-like 156 "shortest path" routing, as the BGP decision process gives priority 157 to other factors, such as the AS_PATH length. Also, the standard 158 procedures for use of the MED do not ensure that the IGP metric is 159 properly accumulated so that it covers all the links along the path. 161 In this document, we define a new optional, non-transitive BGP 162 attribute, called the "Accumulated IGP Metric Attribute", or "AIGP 163 attribute", and specify the procedures for using it. 165 The specified procedures prevent the AIGP attribute from "leaking 166 out" past an administrative domain boundary into the Internet. We 167 will refer to the set of ASes in a common administrative domain as an 168 "AIGP Administrative Domain". 170 The specified procedures also ensure that the value in the AIGP 171 attribute has been accumulated all along the path from the 172 destination, i.e., that the AIGP attribute does not appear when there 173 are "gaps" along the path where the IGP metric is unknown. 175 3. AIGP Attribute 177 The AIGP Attribute is an optional non-transitive BGP Path Attribute. 178 The attribute type code for the AIGP Attribute is 26. 180 The value field of the AIGP Attribute is defined here to be a set of 181 elements encoded as "Type/Length/Value" (i.e., a set of "TLVs"). 182 Each such TLV is encoded as shown in Figure 1. 184 0 1 2 3 185 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Type | Length | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 189 ~ ~ 190 | Value | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 193 AIGP TLV 194 Figure 1 196 - Type: A single octet encoding the TLV Type. Only type 1, "AIGP 197 TLV", is defined in this document. Use of other TLV types is 198 outside the scope of this document. 200 - Length: Two octets encoding the length in octets of the TLV, 201 including the type and length fields. The length is encoded as an 202 unsigned binary integer. (Note that the minimum length is 3, 203 indicating that no value field is present.) 205 - A value field containing zero or more octets. 207 This document defines only a single such TLV, the "AIGP TLV". The 208 AIGP TLV is encoded as follows: 210 - Type: 1 212 - Length: 11 214 - Accumulated IGP Metric. 216 The value field of the AIGP TLV is always 8 octets long, and its 217 value is interpreted as an unsigned 64-bit integer. IGP metrics 218 are frequently expressed as 4-octet values. By using an 8-octet 219 field, we ensure that the AIGP attribute can be used to hold the 220 sum of a arbitrary number of 4-octet values. 222 When an AIGP attribute is created, it SHOULD contain no more than one 223 AIGP TLV. However, if it contains more than one AIGP TLV, only the 224 first one is used as described in Section 3.4 and Section 4. In the 225 remainder of this document, we will use the term "value of the AIGP 226 TLV" to mean the value of the first AIGP TLV in the AIGP attribute. 227 Any other AIGP TLVs in the AIGP attribute MUST be passed along 228 unchanged if the AIGP attribute is passed along. 230 3.1. Applicability Restrictions and Cautions 232 This document only considers the use of the AIGP attribute in 233 networks where each router uses tunneling of some sort to deliver a 234 packet to its BGP next hop. Use of the AIGP attribute in other 235 scenarios is outside the scope of this document. 237 If a Route Reflector supports the AIGP attribute, but some of its 238 clients do not, then the routing choices that result may not all 239 reflect the intended routing policy. 241 3.2. Handling a Malformed AIGP Attribute 243 When receiving a BGP Update message containing a malformed AIGP 244 attribute, the attribute MUST be treated exactly as if it were an 245 unrecognized non-transitive attribute. That is, "it MUST be quietly 246 ignored and not passed along to other BGP peers". This is equivalent 247 to the "attribute discard" action specified in [BGP-ERROR]. 249 Note that an AIGP attribute MUST NOT be considered to be malformed 250 because it contains more than one TLV of a given type, or because it 251 contains TLVs of unknown types. 253 If a BGP Path Attribute is received that has the AIGP attribute 254 codepoint, but also has the transitive bit set, the attribute MUST be 255 considered to be a malformed AIGP attribute, and MUST be discarded as 256 specified in this section. 258 If an AIGP attribute is received, and its first AIGP TLV contains the 259 maximum value 0xffffffffffffffff, the attribute SHOULD be considered 260 to be malformed, and discarded as specified in this section. (Since 261 the TLV value cannot be increased any further, it is not useful for 262 metric-based path selection.) 264 3.3. Restrictions on Sending/Receiving 266 An implementation that supports the AIGP attribute MUST support a 267 per-session configuration item, AIGP_SESSION, that indicates whether 268 the attribute is enabled or disabled for use on that session. 270 - The default value of AIGP_SESSION, for EBGP sessions, MUST be 271 "disabled". 273 - The default value of AIGP_SESSION, for IBGP and confederation- 274 EBGP [BGP-CONFED] sessions, SHOULD be "enabled." 276 The AIGP attribute MUST NOT be sent on any BGP session for which 277 AIGP_SESSION is disabled. 279 If an AIGP attribute is received on a BGP session for which 280 AIGP_SESSION is disabled, the attribute MUST be treated exactly as if 281 it were an unrecognized non-transitive attribute. That is, "it MUST 282 be quietly ignored and not passed along to other BGP peers" (see 283 [BGP], section 5). However, the fact that the attribute was received 284 SHOULD be logged (in a rate-limited manner). 286 3.4. Creating and Modifying the AIGP Attribute 288 3.4.1. Originating the AIGP Attribute 290 An implementation that supports the AIGP attribute MUST support a 291 configuration item, AIGP_ORIGINATE, that enables or disables its 292 creation and attachment to routes. The default value of 293 AIGP_ORIGINATE MUST be "disabled". 295 A BGP speaker MUST NOT add the AIGP attribute to any route whose path 296 leads outside the "AIGP administrative domain" to which the BGP 297 speaker belongs. When the AIGP attribute is used, changes in IGP 298 routing will directly impact BGP routing. Attaching the AIGP 299 attribute to "customer routes", "Internet routes", or other routes 300 whose paths lead outside the infrastructure of a particular AIGP 301 administrative domain, could result in BGP scaling and/or thrashing 302 problems. 304 The AIGP attribute may be added only to routes that satisfy one of 305 the following conditions: 307 - The route is a static route, not leading outside the AIGP 308 administrative domain, that is being redistributed into BGP; 310 - The route is an IGP route that is being redistributed into BGP; 312 - The route is an IBGP-learned route whose AS_PATH attribute is 313 empty; 315 - The route is an EBGP-learned route whose AS_PATH contains only 316 ASes that are in the same AIGP Administrative Domain as the BGP 317 speaker. 319 A BGP speaker R MUST NOT add the AIGP attribute to any route for 320 which R does not set itself as the next hop. 322 It SHOULD be possible to set AIGP_ORIGINATE to "enabled for the 323 routes of a particular IGP that are redistributed into BGP" (where "a 324 particular IGP" might be "OSPF" or "ISIS"). Other policies 325 determining when and whether to originate an AIGP attribute are also 326 possible, depending on the needs of a particular deployment scenario. 328 When originating an AIGP attribute for a BGP route to address prefix 329 P, the value of the AIGP TLV is set according to policy. There are a 330 number of useful policies, some of which are in the following list: 332 - When a BGP speaker R is redistributing into BGP an IGP route to 333 address prefix P, the IGP will have computed a "distance" from R 334 to P. This distance MAY be assigned as the value of the AIGP 335 TLV. 337 - A BGP speaker R may be redistributing into BGP a static route to 338 address prefix P, for which a "distance" from R to P has been 339 configured. This distance MAY be assigned as the value of the 340 AIGP TLV. 342 - A BGP speaker R may have received and installed a BGP-learned 343 route to prefix P, with next hop N. Or it may be redistributing 344 a static route to P, with next hop N. Then: 346 * If R has an IGP route to N, the IGP-computed distance from R 347 to N MAY be used as the value of the AIGP TLV of the route to 348 P. 350 * If R has a BGP route to N, and an AIGP TLV attribute value 351 has been computed for that route (see section 3.4.3), that 352 value MAY be used as the AIGP TLV value of the route to P. 354 3.4.2. Modifications by the Originator 356 If BGP speaker R is the originator of the AIGP attribute of prefix P, 357 and at some point the "distance" from R to P changes, R SHOULD issue 358 a new BGP update containing the new value of the AIGP TLV of the AIGP 359 attribute. (Here we use the term "distance" to refer to whatever 360 value the originator assigns to the AIGP TLV, however it is computed; 361 see section 3.4.1.) However, if the difference between the new 362 distance and the distance advertised in the AIGP TLV is less than a 363 configurable threshold, the update MAY be suppressed. 365 3.4.3. Modifications by a Non-Originator 367 Suppose a BGP speaker R1 receives a route with an AIGP attribute 368 whose value is A, and a Next Hop whose value is R2. Suppose also 369 that R1 is about to redistribute that route on a BGP session that is 370 enabled for sending/receiving the attribute. 372 If R1 does not change the Next Hop of the route, then R1 MUST NOT 373 change the AIGP attribute value of the route. 375 In all the computations discussed in this section, the AIGP value 376 MUST be capped at its maximum unsigned value 0xffffffffffffffff. 377 Increasing the AIGP value MUST NOT cause the value to wrap around. 379 Suppose R1 changes the Next Hop of the route from R2 to R1. If R1's 380 route to R2 is either (a) an IGP-learned route or (b) a static route 381 that does not require recursive next hop resolution, then R1 MUST 382 increase the value of the AIGP TLV by adding to A the distance from 383 R1 to R2. This distance is either the IGP-computed distance from R1 384 to R2, or some value determined by policy. However, A MUST be 385 increased by a non-zero amount. 387 It is possible that R1 and R2 above are EBGP neighbors, and that 388 there is a direct link between them on which no IGP is running. Then 389 when R1 changes the next hop of a route from R2 to R1, the AIGP TLV 390 value MUST be increased by a non-zero amount. The amount of the 391 increase SHOULD be such that it is properly comparable to the IGP 392 metrics. E.g., if the IGP metric is a function of latency, then the 393 amount of the increase should be a function of the latency from R1 to 394 R2. 396 Suppose R1 changes the Next Hop of the route from R2 to R1, and R1's 397 route to R2 is either (a) a BGP-learned route or (b) a static route 398 that requires recursive next hop resolution. Then the AIGP TLV value 399 needs to be increased in several steps, according to the following 400 procedure. (Note that this procedure is ONLY used when recursive 401 next hop resolution is needed.) 403 1. Let Xattr be the new AIGP TLV value. 405 2. Initialize Xattr to A. 407 3. Set the XNH to R2. 409 4. Find the route to XNH. 411 5. If the route to XNH does not require recursive next hop 412 resolution, get the distance D from R1 to XNH. (Note that this 413 condition cannot be satisfied the first time through this 414 procedure.) If D is above a configurable threshold, set the 415 AIGP TLV value to Xattr+D. If D is below a configurable 416 threshold, set the AIGP TLV value to Xattr. In either case, 417 exit this procedure. 419 6. If the route to XNH is a BGP-learned route that does NOT have 420 an AIGP attribute, then exit this procedure and do not pass on 421 any AIGP attribute. If the route has an AIGP attribute without 422 an AIGP TLV, then the AIGP attribute MAY be passed along 423 unchanged. 425 7. If the route to XNH is a BGP-learned route that has an AIGP TLV 426 value of Y, then set Xattr=Xattr+Y and set XNH to the next hop 427 of this route. (The intention here is that Y is the AIGP TLV 428 value of the route as it was received by R1, without having 429 been modified by R1.) 431 8. Go to step 4. 433 The AIGP TLV value of a given route depends on (a) the AIGP TLV 434 values of all the next hops that are recursively resolved during this 435 procedure, and (b) the IGP distance to any next hop that is not 436 recursively resolved. Any change due to (a) in any of these values 437 MUST trigger a new AIGP computation for that route. Whether a change 438 due to (b) triggers a new AIGP computation depends upon whether the 439 change in IGP distance exceeds a configurable threshold. 441 If the AIGP attribute is carried across several ASes, each with its 442 own IGP domain, it is clear that these procedures are unlikely to 443 give a sensible result if the IGPs are different (e.g., some OSPF and 444 some IS-IS), or if the meaning of the metrics is different in the 445 different IGPs (e.g., if the metric represents bandwidth in some IGP 446 domains but represents latency in others). These procedures also are 447 unlikely to give a sensible result if the metric assigned to inter-AS 448 BGP links (on which no IGP is running) or to static routes is not 449 comparable to the IGP metrics. All such cases are outside the scope 450 of the current document. 452 4. Decision Process 454 Support for the AIGP attribute involves several modifications to the 455 tie breaking procedures of the BGP "phase 2" decision described in 456 [BGP], section 9.1.2.2. These modifications are described below in 457 sections 4.1 and 4.2. 459 In some cases, the BGP decision process may install a route without 460 executing any tie breaking procedures. This may happen, e.g., if 461 only one route to a given prefix has the highest degree of preference 462 (as defined in [BGP] section 9.1.1). In this case, the AIGP 463 attribute is not considered. 465 In other cases, some routes may be eliminated before the tie breaking 466 procedures are invoked, e.g., routes with AS-PATH attributes 467 indicating a loop, or routes with unresolvable next hops. In these 468 cases, the AIGP attributes of the eliminated routes are not 469 considered. 471 4.1. When a Route has an AIGP Attribute 473 Assuming that the BGP decision process invokes the tie breaking 474 procedures, the procedures in this section MUST be executed BEFORE 475 any of the tie breaking procedures described in [BGP] section 9.1.2.2 476 are executed. 478 If any routes have an AIGP attribute containing an AIGP TLV, remove 479 from consideration all routes that do not have an AIGP attribute 480 containing an AIGP TLV. 482 If router R is considering route T, where T has an AIGP attribute 483 with an AIGP TLV, 485 - then R must compute the value A, defined as follows: set A to the 486 sum of (a) T's AIGP TLV value and (b) the IGP distance from R to 487 T's next hop. 489 - remove from consideration all routes that are not tied for the 490 lowest value of A. 492 4.2. When the Route to the Next Hop has an AIGP attribute 494 Suppose that a given router R1 is comparing two BGP-learned routes, 495 such that either: 497 - the two routes have equal AIGP TLV values, or else 499 - neither of the two routes has an AIGP attribute containing an 500 AIGP TLV. 502 The BGP decision process as specified in [BGP] makes use, in its tie 503 breaker procedures, of "interior cost", defined as follows: 505 "interior cost of a route is determined by calculating the metric 506 to the NEXT_HOP for the route using the Routing Table." 508 This document replaces the "interior cost" tie breaker of [BGP] with 509 a tie breaker based on the "AIGP-enhanced interior cost". Suppose 510 route T has a next hop of N. The "AIGP-enhanced interior cost" from 511 node R1 to node N is defined as follows: 513 - Let R2 be the BGP next hop of the route to N after all recursive 514 resolution of the next hop is done. Let m be the IGP distance 515 (or in the case of a static route, the configured distance) from 516 R1 to R2. 518 - If the installed route to N has an AIGP attribute with an AIGP 519 TLV, set A to its AIGP TLV value, computed according to the 520 procedure of section 3.4.3. 522 - If the installed route to N does not have an AIGP attribute with 523 an AIGP TLV, set A to 0. 525 - The "AIGP-enhanced interior cost" of route T is the quantity A+m. 527 The "interior cost" tie breaker of [BGP] is then applied, but using 528 the "AIGP-enhanced interior cost" instead of the "interior cost" as 529 defined in [BGP]. 531 5. Deployment Considerations 533 - Using the AIGP attribute to achieve a desired routing policy will 534 be more effective if each BGP speaker can use it to choose from 535 among multiple routes. Thus is it highly recommended that the 536 procedures of [BESTEXT] and [ADD-PATH] be used in conjunction 537 with the AIGP Attribute. 539 - If a Route Reflector does not pass all paths to its clients, then 540 it will tend to pass the paths for which the IGP distance from 541 the Route Reflector itself to the next hop is smallest. This may 542 result in a non-optimal choice by the clients. 544 - When the procedures of this document are deployed, it must be 545 understood that frequent changes of the IGP distance towards a 546 certain prefix may result in equally frequent transmission of BGP 547 updates about that prefix. 549 - In an IGP deployment, there are certain situations in which a 550 network link may be temporarily assigned a metric whose value is 551 the maximum metric value (or close to the maximum) for that IGP. 552 This is known as "costing out" the link. A link may be "costed 553 out" to deflect traffic from the link before the link is actually 554 brought down, or to discourage traffic from using a link until 555 all the necessary state for that link has been set up (e.g., 556 [LDP-IGP-SYNC]). This assumes of course that a path containing a 557 "costed out" link will have a total distance that is larger than 558 any alternate path within the same IGP area; in that case the 559 normal IGP decision process will choose the path that does not 560 contain the costed out link. 562 Costing out a link will have the same effect on BGP routes that 563 carry the AIGP attribute. The value of the AIGP TLV will be 564 larger for a route (to a given prefix) that contains a "costed 565 out" link than for a route (to the same prefix) that does not. 566 It must be understood though that a route that carries an AIGP 567 attribute will be preferred to a route that does not, no matter 568 what the value of the AIGP TLV is. This is similar to the 569 behavior in, e.g., an OSPF area, where an intra-area route is 570 preferred to an inter-area or external route, even if the intra- 571 area route's distance is large. 573 6. IANA Considerations 575 IANA has assigned the codepoint 26 in the "BGP Path Attributes" 576 registry to the AIGP attribute. 578 IANA shall create a registry for "BGP AIGP Attribute Types". The 579 type field consists of a single octet, with possible values from 1 to 580 255. (The value 0 is "reserved".) The allocation policy for this 581 field is to be "Standards Action". Type 1 should be defined as 582 "AIGP", and should refer to this document. 584 7. Security Considerations 586 The spurious introduction, though error or malfeasance, of an AIGP 587 attribute, could result in the selection of paths other than those 588 desired. 590 Improper configuration on both ends of an EBGP connection could 591 result in an AIGP attribute being passed from one service provider to 592 another. This would likely result in an unsound selection of paths. 594 8. Acknowledgments 596 The authors would like to thank Waqas Alam, Rajiv Asati, Alia Atlas, 597 Ron Bonica, Bruno Decraene, Brian Dickson, Clarence Filsfils, Anoop 598 Kapoor, Pratima Kini, Sue Hares, Thomas Mangin, Robert Raszuk, Yakov 599 Rekhter, Eric Rosenberg, Samir Saad, John Scudder, Shyam Sethuram, 600 and Ilya Varlashkin for their input. 602 9. Authors' Addresses 604 Rex Fernando 605 Cisco Systems, Inc. 606 170 Tasman Drive 607 San Jose, CA 95134 608 Email: rex@cisco.com 610 Pradosh Mohapatra 611 Cumulus Networks 612 Email: pmohapat@cumulusnetworks.com 613 Eric C. Rosen 614 Cisco Systems, Inc. 615 1414 Massachusetts Avenue 616 Boxborough, MA, 01719 617 Email: erosen@cisco.com 619 James Uttaro 620 AT&T 621 200 S. Laurel Avenue 622 Middletown, NJ 07748 623 Email: uttaro@att.com 625 10. Normative References 627 [BGP], "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, S. 628 Hares, RFC 4271, January 2006. 630 11. Informative References 632 [ADD-PATH] "Advertisement of Multiple Paths in BGP", D. Walton, A. 633 Retana, E. Chen, J. Scudder, draft-ietf-idr-add-paths-09.txt, October 634 2013. 636 [BESTEXT], "Advertisement of the Best External Route in BGP", P. 637 Marques, R. Fernando, E. Chen, P. Mohapatra, H. Gredler, draft-ietf- 638 idr-best-external-05.txt, January 2012. 640 [BGP-CONFED] "Autonomous System Confederations for BGP", P. Traina, 641 D. McPherson, J. Scudder, RFC 5065, August 2007 643 [BGP-ERROR] "Revised Error Handling for BGP UPDATE Messages", J. 644 Scudder, E. Chen, P. Mohapatra, K. Patel, draft-ietf-idr-error- 645 handling-06.txt, February 2014. 647 [LDP-IGP-SYNC] "LDP IGP Synchronization", M. Jork, A. Atlas, L. Fang, 648 RFC 5443, March 2009. 650 [RFC2119] "Key words for use in RFCs to Indicate Requirement 651 Levels.", S. Bradner, March 1997.