idnits 2.17.1 draft-ietf-idr-aigp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 7, 2009) is 5314 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 (-03) exists of draft-pmohapat-idr-fast-conn-restore-00 Summary: 1 error (**), 0 flaws (~~), 2 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 Cisco Systems, Inc. 4 Intended Status: Proposed Standard 5 Expires: April 7, 2010 Rex Fernando 6 Juniper Networks, Inc. 8 Eric C. Rosen 9 Cisco Systems, Inc. 11 James Uttaro 12 ATT 14 October 7, 2009 16 The Accumulated IGP Metric Attribute for BGP 18 draft-ietf-idr-aigp-01.txt 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright and License Notice 43 Copyright (c) 2009 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents in effect on the date of 48 publication of this document (http://trustee.ietf.org/license-info). 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. 52 Abstract 54 Routing protocols that have been designed to run within a single 55 administrative domain ("IGPs") generally do so by assigning a metric 56 to each link, and then choosing as the installed path between two 57 nodes the path for which the total distance (sum of the metric of 58 each link along the path) is minimized. BGP, designed to provide 59 routing over a large number of independent administrative domains 60 ("autonomous systems"), does not make its path selection decisions 61 through the use of a metric. It is generally recognized that any 62 attempt to do so would incur significant scalability problems, as 63 well as inter-administration coordination problems. However, there 64 are deployments in which a single administration runs several 65 contiguous BGP networks. In such cases, it can be desirable, within 66 that single administrative domain, for BGP to select paths based on a 67 metric, just as an IGP would do. The purpose of this document is to 68 provide a specification for doing so. 70 Table of Contents 72 1 Specification of requirements ......................... 3 73 2 Introduction .......................................... 3 74 3 AIGP Attribute ........................................ 5 75 3.1 Applicability Restrictions and Cautions ............... 6 76 3.2 Restrictions on Sending/Receiving ..................... 6 77 3.3 Creating and Modifying the AIGP Attribute ............. 7 78 3.3.1 Originating the AIGP Attribute ........................ 7 79 3.3.2 Modifications by the Originator ....................... 7 80 3.3.3 Modifications by a Non-Originator ..................... 8 81 4 Decision Process ...................................... 9 82 4.1 When a Route has an AIGP Attribute .................... 9 83 4.2 When the Route to the Next Hop has an AIGP attribute .. 10 84 5 Deployment Considerations ............................. 11 85 6 IANA Considerations ................................... 11 86 7 Security Considerations ............................... 11 87 8 Acknowledgments ....................................... 11 88 9 Authors' Addresses .................................... 12 89 10 Normative References .................................. 12 90 11 Informative References ................................ 13 92 1. Specification of requirements 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Introduction 100 There are many routing protocols that have been designed to run 101 within a single administrative domain. These are known collectively 102 as "Interior Gateway Protocols" (IGPs). Typically, each link is 103 assigned a particular "metric" value. The path between two nodes can 104 then be assigned a "distance", which is the sum of the metrics of all 105 the links that belong to that path. An IGP selects the "shortest" 106 (minimal distance) path between any two nodes, perhaps subject to the 107 constraint that if the IGP provides multiple "areas", it may prefer 108 the shortest path within an area to a path that traverses more than 109 one area. Typically the administration of the network has some 110 routing policy which can be approximated by selecting shortest paths 111 in this way. 113 BGP, as distinguished from the IGPs, was designed to run over an 114 arbitrarily large number of administrative domains ("autonomous 115 systems", or "ASes") with limited coordination among the various 116 administrations. BGP does not make its path selection decisions 117 based on a metric; there is no such thing as an "inter-AS metric". 118 There are two fundamental reasons for this: 120 - The distance between two nodes in a common administrative domain 121 may change at any time due to events occurring in that domain. 122 These changes are not propagated around the Internet unless they 123 actually cause the border routers of the domain to select routes 124 with different BGP attributes for some set of address prefixes. 125 This accords with a fundamental principle of scaling, viz., that 126 changes with only local significance must not have global 127 effects. If local changes in distance were always propagated 128 around the Internet, this principle would be violated. 130 - A basic principle of inter-domain routing is that the different 131 administrative domains may have their own policies, which do not 132 have to be revealed to other domains, and which certainly do not 133 have to be agreed to by other domains. Yet the use of inter-AS 134 metric in the Internet would have exactly these effects. 136 There are, however, deployments in which a single administration runs 137 a network which has been sub-divided into multiple, contiguous ASes, 138 each running BGP. There are several reasons why a single 139 administrative domain may be broken into several ASes (which, in this 140 case, are not really "autonomous".) It may be that the existing IGPs 141 do not scale well in the particular environment; it may be that a 142 more generalized topology is desired than could be obtained by use of 143 a single IGP domain; it may be that a more finely grained routing 144 policy is desired than can be supported by an IGP. In such 145 deployments, it can be useful to allow BGP to make its routing 146 decisions based on the IGP metric, so that BGP chooses the "shortest" 147 path between two nodes, even if the nodes are in two different ASes 148 within that same administrative domain. 150 There are in fact some implementations which already do something 151 like this, using the MULTI_EXIT_DISC (MED) attribute to carry the IGP 152 metric. However, that doesn't really provide IGP-like "shortest 153 path" routing, as the BGP decision process gives priority to other 154 factors, such as LOCAL_PREF and AS_PATH length. Also, the standard 155 procedures for use of the MED do not ensure that the IGP metric is 156 properly accumulated so that it covers all the links along the path. 158 In this document, we define a new optional, non-transitive BGP 159 attribute, called the "Accumulated IGP Metric Attribute", or "AIGP 160 attribute", and specify the procedures for using it. 162 The specified procedures prevent the AIGP attribute from "leaking 163 out" past the administrative domain boundaries into the Internet. 165 The specified procedures also ensure that the value in the AIGP 166 attribute has been accumulated all along the path from the 167 destination, i.e., that the AIGP attribute does not appear when there 168 are "gaps" along the path where the IGP metric is unknown. 170 3. AIGP Attribute 172 The AIGP Attribute is an optional non-transitive BGP Path Attribute. 173 The attribute type code for the AIGP Attribute is to be assigned by 174 IANA. The value field of the AIGP Attribute is defined here to be a 175 set of TLVs (elements encoded as "Type/Length/Value"). However, this 176 document defines only a single such TLV, the AIGP TLV, that contains 177 the Accumulated IGP Metric. The AIGP TLV is encoded as shown in 178 Figure 1. An AIGP Attribute MUST NOT contain more than one AIGP TLV. 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type=1 | Length | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 185 ~ ~ 186 | Accumulated IGP Metric | 187 | +-+-+-+-+-+-+-+-+ 188 | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 AIGP Attribute 192 Figure 1 194 - Type: A single octet encoding the AIGP Attribute Type. Only type 195 1 is defined in this document. 197 - Length: Two octets encoding the length in octets of the attribute, 198 including the type and length fields. The length is encoded as an 199 unsigned binary integer. 201 The length of the AIGP TLV is always 11. 203 - Accumulated IGP Metric: For a type 1 AIGP attribute, the value 204 field is always 8 bytes long. IGP metrics are frequently 205 expressed as 4-octet values, and this ensures that the AIGP 206 attribute can be used to hold the sum of an arbitrary number of 207 4-octet values. 209 3.1. Applicability Restrictions and Cautions 211 This document only considers the use of the AIGP attribute in 212 networks where each router uses tunneling of some sort to deliver a 213 packet to its BGP next hop. Use of the AIGP attribute in networks 214 that do not use tunneling is outside the scope of this document. 216 If a Route Reflector supports the AIGP attribute, but some of its 217 clients do not, then the routing choices that result may not all 218 reflect the intended routing policy. 220 3.2. Restrictions on Sending/Receiving 222 An implementation that supports the AIGP attribute MUST support a 223 per-session configuration item, AIGP_SESSION, that indicates whether 224 the attribute is enabled or disabled for use on that session. 226 - The default value of AIGP_SESSION, for EBGP sessions, MUST be 227 "disabled". 229 - The default value of AIGP_SESSION, for IBGP and confederation- 230 EBGP sessions, MUST be "enabled." 232 The AIGP attribute MUST NOT be sent on any BGP session for which 233 AIGP_SESSION is disabled. 235 If an AIGP attribute is received on a BGP session for which 236 AIGP_SESSION is disabled, the attribute MUST be treated exactly as if 237 it were an unrecognized non-transitive attribute. That is, "it MUST 238 be quietly ignored and not passed along to other BGP peers" (see 239 [BGP], section 5). 241 3.3. Creating and Modifying the AIGP Attribute 243 3.3.1. Originating the AIGP Attribute 245 A BGP speaker MUST NOT add the AIGP attribute to any route whose path 246 leads outside the AS to which the BGP speaker belongs. It may be 247 added only to routes that satisfy one of the following conditions: 249 - The route is a static route that is being redistributed into BGP 251 - The route is an IGP route that is being redistributed into BGP 253 - The route is an IBGP-learned route whose AS_PATH attribute is 254 empty. 256 An implementation that supports the AIGP attribute MUST support a 257 configuration item, AIGP_ORIGINATE, that enables or disables its 258 creation and attachment to routes. The default value of 259 AIGP_ORIGINATE MUST be "disabled". 261 It SHOULD be possible to set AIGP_ORIGINATE to "enabled for the 262 routes of a particular IGP that are redistributed into BGP" (where "a 263 particular IGP" might be "OSPF" or "ISIS"). 265 When a BGP speaker R learns a route to address prefix P from an IGP, 266 the IGP will have computed a "distance" from R to P. The value 267 assigned to the AIGP attribute is either the IGP-computed distance, 268 or some other value determined by policy. 270 In the case of a static route whose next hop matches a BGP route that 271 has an AIGP attribute, the static route MAY inherit the AIGP 272 attribute value of that BGP route. 274 3.3.2. Modifications by the Originator 276 If BGP speaker R is the originator of the AIGP attribute of prefix P, 277 and at some point the distance from R to P changes, R SHOULD issue a 278 new BGP update containing the new value of the AIGP attribute. 279 However, if the difference between the new distance and the distance 280 advertised in the AIGP attribute is less than a configurable 281 threshold, the update MAY be suppressed. 283 3.3.3. Modifications by a Non-Originator 285 Suppose a BGP speaker R1 receives a route with an AIGP attribute 286 whose value is A, and a Next Hop whose value is R2. Suppose also 287 that R1 is about to redistribute that route on a BGP session that is 288 enabled for sending/receiving the attribute. 290 If R1 does not change the Next Hop of the route, then R1 MUST NOT 291 change the AIGP attribute value of the route. 293 If R1 changes the Next Hop of the route from R2 to R1, and if R1's 294 route to R2 is an IGP-learned route, or a static route that does not 295 require recursive next hop resolution, then R1 must increase the 296 value of the AIGP attribute by adding to A the distance from R1 to 297 R2. This distance is either the IGP-computed distance from R1 to R2, 298 or some value determined by policy. However, A MUST be increased by 299 a non-zero amount. 301 Note that if R1 and R2 above are EBGP neighbors, and there is a 302 direct link between them on which no IGP is running, then when R1 303 changes the next hop of a route from R2 to R1, the AIGP metric value 304 MUST be increased by a non-zero amount. The amount of the increase 305 SHOULD be such that it is properly comparable to the IGP metrics. 306 E.g., if the IGP metric is a function of latency, then the amount of 307 the increase should be a function of the latency from R1 to R2. 309 If R1 changes the Next Hop of the route from R2 to R1, and if R1's 310 route to R2 is a BGP-learned route, or a static route that requires 311 recursive next hop resolution, then the AIGP attribute value needs to 312 be increased in several steps: 314 1. Let Xattr be the new AIGP attribute value. 316 2. Initialize Xattr to A. 318 3. Set the XNH to R2. 320 4. Find the route to XNH. 322 5. If the route to XNH does not require recursive next hop 323 resolution, get the distance D from R1 to XNH. If D is above a 324 configurable threshold, set the AIGP attribute value to 325 Xattr+D. If D is below a configurable threshold, set the AIGP 326 attribute value to Xattr. In either case, exit this procedure. 328 6. If the route to XNH is a BGP-learned route, and the route does 329 NOT have an AIGP attribute, then exit this procedure and do not 330 pass on any AIGP attribute. 332 7. If the route to XNH is a BGP-learned route, and the route has 333 an AIGP attribute value of Y, then set Xattr=Xattr+Y, and set 334 XNH to the next hop of this route. (The intention here is that 335 Y is the AIGP value of the route as it was received by R1, 336 without having been modified by R1.) 338 8. Go to step 4. 340 The AIGP value of a given route depends on (a) the AIGP values of all 341 the next hops that are recursively resolved during this procedure, 342 and (b) the IGP distance to any next hop that is not recursively 343 resolved. Any change due to (a) in any of these values MUST trigger 344 a new AIGP computation for that route. Whether a change due to (b) 345 triggers a new AIGP computation depends upon whether the change in 346 IGP distance exceeds a configurable threshold. 348 Note that the overall shortest path may not be selected if the next 349 hop has to be recursively resolved more than once. 351 If the AIGP attribute is carried across several ASes, each with its 352 own IGP domain, it is clear that these procedures are unlikely to 353 give a sensible result if the IGPs are different (e.g., some OSPF and 354 some IS-IS), or if the meaning of the metrics is different in the 355 different IGPs (e.g., if the metric represents bandwidth in some IGP 356 domains but represents latency in others). These procedures also are 357 unlikely to give a sensible result if the metric assigned to inter-AS 358 BGP links (on which no IGP is running) or to static routes is not 359 comparable to the IGP metrics. All such cases are outside the scope 360 of the current document. 362 4. Decision Process 364 4.1. When a Route has an AIGP Attribute 366 Use of the AIGP attribute involves several modifications to the BGP 367 "phase 2" decision process as described in [BGP], section 9.1.2.2. 368 The procedures defined in this section MUST be executed BEFORE any of 369 the tie breaking procedures described therein are executed. 371 If any routes have an AIGP attribute, remove from consideration all 372 routes that do not have an AIGP attribute. 374 If router R is considering route T, where T has an AIGP attribute, 376 - then R must compute the value A, defined as follows: set A to the 377 sum of (a) T's AIGP attribute value and (b) the IGP distance from 378 R to T's next hop. 380 - remove from consideration all routes that are not tied for the 381 lowest value of A. 383 4.2. When the Route to the Next Hop has an AIGP attribute 385 Suppose that a given router R1 is comparing two routes, neither of 386 which has an AIGP attribute. The BGP decision process as specified 387 in [BGP] makes use, in its tie breaker procedures, of "interior 388 cost", defined as follows: 390 "interior cost of a route is determined by calculating the metric 391 to the NEXT_HOP for the route using the Routing Table." 393 Suppose route T has a next hop of N. We modify the notion of the 394 "interior cost" from node R to node N as follows: 396 - If the route to N has an AIGP attribute, set A to the AIGP value 397 of the route to N, computing the AIGP value of the route 398 according to the procedure of section 3.3.3. (This will have 399 been computed at the time the route to N was installed.) 401 - If the route to N does not have an AIGP value, set A to 0. (This 402 can only be the case if there is no route to N that does have an 403 AIGP value.) 405 - Let R2 be the next hop of the route to N, after all recursive 406 resolution of the next hop is done. Let m be the IGP distance 407 (or in the case of a static route, the configured distance) from 408 R1 to R2. 410 - The "interior cost" of route T is the quantity A+m. 412 5. Deployment Considerations 414 Using the AIGP attribute to achieve a desired routing policy will be 415 more effective if each BGP speaker can use it to choose from among 416 multiple routes. Thus is it highly recommended that the procedures of 417 [BESTEXT] and [ADDPATH] be used in conjunction with the AIGP 418 Attribute. 420 If a Route Reflector does not pass all paths to its clients, then it 421 will tend to pass the paths for which the IGP distance from the Route 422 Reflector itself to the next hop is smallest. This may result in a 423 non-optimal choice by the clients. 425 6. IANA Considerations 427 IANA shall assign a codepoint for the AIGP attribute. This codepoint 428 will come from the "BGP Path Attributes" registry. 430 IANA shall create a registry for "BGP AIGP Attribute Types". Type 1 431 should be defined as "AIGP", and should refer to this document. 433 7. Security Considerations 435 The spurious introduction, though error or malfeasance, of an AIGP 436 attribute, could result in the selection of paths other than those 437 desired. 439 Improper configuration on both ends of an EBGP connection could 440 result in an AIGP attribute being passed from one service provider to 441 another. This would likely result in an unsound selection of paths. 443 8. Acknowledgments 445 The authors would like to thank Rajiv Asati, Clarence Filsfils, 446 Robert Raszuk, Yakov Rekhter, Samir Saad, and John Scudder for their 447 input. 449 9. Authors' Addresses 451 Rex Fernando 452 Juniper Networks 453 1194 N. Mathilda Ave 454 Sunnyvale, CA 94089 455 USA 456 Email: rex@juniper.net 458 Pradosh Mohapatra 459 Cisco Systems, Inc. 460 170 Tasman Drive 461 San Jose, CA 95134 462 Email: pmohapat@cisco.com 464 Eric C. Rosen 465 Cisco Systems, Inc. 466 1414 Massachusetts Avenue 467 Boxborough, MA, 01719 468 Email: erosen@cisco.com 470 James Uttaro 471 AT&T 472 200 S. Laurel Avenue 473 Middletown, NJ 07748 474 Email: uttaro@att.com 476 10. Normative References 478 [BGP], "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, S. 479 Hares, RFC 4271, January 2006. 481 11. Informative References 483 [ADDPATH] "Fast Connectivity Restoration Using BGP Add-Path", P. 484 Mohapatra, R. Fernando, C. Filsfils, R. Raszuk, draft-pmohapat-idr- 485 fast-conn-restore-00.txt, September 2008. 487 [BESTEXT], " Advertisement of the Best-External Route to IBGP", P. 488 Marques, R. Fernando, E. Chen, P. Mohapatra, draft-marques-idr-best- 489 external-01.txt, March 2009. 491 [RFC2119] "Key words for use in RFCs to Indicate Requirement 492 Levels.", S. Bradner, March 1997