idnits 2.17.00 (12 Aug 2021) /tmp/idnits10375/draft-marques-idr-aggregate-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 117: '...es such a prefix MUST compare the rece...' RFC 2119 keyword, line 122: '... "Inactive". It SHOULD NOT be further...' RFC 2119 keyword, line 123: '...GP sessions. It MAY BE re-advertised ...' RFC 2119 keyword, line 242: '...e AGGREGATE_INFO attribute SHOULD be a...' RFC 2119 keyword, line 248: '...n implementation MAY choose to include...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 21, 2010) is 4162 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 1700 (Obsoleted by RFC 3232) 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 P. Marques, Ed. 3 Internet-Draft R. White 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: June 24, 2011 December 21, 2010 7 Topology-based aggregation 8 draft-marques-idr-aggregate-00 10 Abstract 12 This document defines a mechanism which allows more-specific IP 13 address prefixes to be aggregated when they are topologically 14 equivalent or less preferable than a less-specific advertisement. 16 It is designed to allow multi-homed sites to use "Provider 17 Aggregatable" (PA) addresses and obtain both redundancy and local 18 traffic optimizations when using multiple service providers. 20 Status of this Memo 22 This Internet-Draft is submitted 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). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on June 24, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Topology-based aggregation . . . . . . . . . . . . . . . . . . 4 56 3. BGP AGGREGATE_INFO attribute . . . . . . . . . . . . . . . . . 6 57 4. BGP extension deployment . . . . . . . . . . . . . . . . . . . 8 58 5. Path selection criteria . . . . . . . . . . . . . . . . . . . 8 59 6. Network deployment . . . . . . . . . . . . . . . . . . . . . . 9 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 61 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 66 11.2. Informative References . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 With the existing inter-domain routing functionality as defined by 72 RFC 4271 [RFC4271], multi-homed sites feel compelled to advertise 73 their individual prefixes to the entire Internet in order to achieve 74 the desired reliability and traffic-engineering behavior. 76 Multi-homed sites typically advertise "Provider Independent" (PI) 77 prefixes. An alternative approach would be for "Provider 78 Aggregatable" (PA) space to be used along with a set of procedures 79 that allow for route advertisements to be aggregated. This option 80 must retain the functionality that is provided today by PI 81 advertisements. 83 One assumption made here is that renumbering of a multi-homed site is 84 economically feasible given the increased usage of dynamic host 85 configuration protocols and/or network address translation. 87 This document is being written at a time when IP addresses are 88 becoming scarse. It is difficult to predict whether Internet address 89 allocation and assignment policies will drift torwards the use of PI 90 space in order to achieve more efficient allocation. Or whether 91 scarcity will make it harder to obtain PI space. 93 In the latter case, this document define an approach that would allow 94 multi-homed sites a method for using PA addresses without bumping 95 into address space filtering rules that may be in place to limit the 96 growth of the internet table size. 98 In order to meet the requirements stated above for multi-home site 99 routing, the following is proposed: 101 The routing advertisement must be taken out of "Provider 102 Aggregatable" (PA) space. 104 The routing advertisement must be leaked through one or more 105 alternate providers, other than the one owning the PA space. 107 These more-specific route advertisements shall be automatically 108 aggregated, depending on the network topology. 110 If the multi-homed site becomes disconnected from the owner of the 111 address space it must be possible to unsuppress the most-specific 112 adververtisement. 114 In order to provide topology-dependent aggregation, this document 115 defines a new BGP path attribute, AGGREGATE_INFO, which defines a BGP 116 prefix as being a more specific of a given aggregate prefix. A BGP 117 speaker that receives such a prefix MUST compare the received prefix 118 with the specified aggregate, if present in its Loc-RIB. The 119 standard path selection algorithm is applied between the paths of the 120 more-specific prefix and the best-path of the aggregate. If the 121 best-path of the aggregate is preferable, the more-specific prefix 122 should be considered as "Inactive". It SHOULD NOT be further re- 123 advertised into External BGP sessions. It MAY BE re-advertised into 124 Internal BGP sessions, if the path-selection criteria between the 125 aggregate and more-specific justifies it. 127 Conceptually, the aggregate prefix conveys implicit path information 128 that applies to the delegated more-specifics. Path selection occurs 129 between the explicit paths that are present in the routing system and 130 these implicit paths represented by the aggregates. 132 The AGGREGATE_INFO attribute contains an operational status field. 133 This field is used to indicate the status of the connectivity between 134 the multi-homed site and the provider owning the aggregate. It can 135 be used in a situation of failure in which the customer becomes 136 detached from the service provider originating the PA aggregate. 138 When the operational status denotes connectivity failure this will 139 result on the more-specific being unsuppressed and attracting traffic 140 through the failover paths. The operational status is used 141 explicitly in order to inform downstreams that the more-specific is 142 temporary and will be removed from the routing system once 143 connectivity is restored. 145 The operational status field uses three colors: green, yellow and 146 red. Green means full connectivity. Red means no connectivity. 147 Yellow informs the routing system that while the site itself has no 148 direct connectivity to the primary provider, it believes that there 149 is sufficient redundant connectivity in the network that its prefix 150 is still reachable through it. 152 2. Topology-based aggregation 154 The intent of this extension is to achieve the same semantics as 155 "Provider Independent" (PI) advertisements, while removing the more 156 specifics from the BGP routing table in locations of the network 157 where the aggregate provides equal or better service to the IP 158 destination prefix in question. 160 +------+ 161 | AS 10| 162 +------+ 163 / \ 164 / \ 165 +------+ +------+ 166 | AS 1 | | AS 2 | 167 +------+ +------+ 168 | \ / | 169 | \ / | 170 | \/ | 171 | /\ | 172 | / \ | 173 | / \ | 174 +------+ +------+ 175 | AS 3 | | AS 4 | 176 +------+ +------+ 177 \ / 178 \ / 179 +------+ 180 | AS 20| 181 +------+ 183 Figure 1 185 Figure 1 contains an example of the usage of the BGP AGGREGATE_INFO 186 attribute. AS 10 in the example above has been delegated "10.0.1/24" 187 prefix by AS 1. Using this extension, it will advertise the prefix 188 into AS 2, which will likely prefer a customer router over a peer 189 route to AS 1. When AS 2 re-advertises the more-specific "10.0.1/24" 190 to its peers, AS 3 and 4 in this example, the peers will compare the 191 more-specific to the "10.0/16" aggregate received from AS 1. 192 Typically AS 3 will prefer the aggregate (as-path: "1", length 1) 193 over the more-specific (as-path: "2 10", length: 2). When this is 194 the case, the more-specific will be suppressed and no longer 195 propagated in the network. If, for any reason, AS 1 becomes 196 disconnected from AS 3, the more-specific route to "10.0.1/24" will 197 become active again, achieving the required failover protection. 199 From a traffic-engineering perspective, the more-specific is selected 200 in locations in the network where AS 10 is topologically closer than 201 AS 1. 203 In the example described above, the aggregate route may have a 204 shorter as-path than the equivalent PI prefix that is in use 205 currently. A PI prefix that is injected by the customer AS (AS 10) 206 would be advertised to AS 3 with an as-path of "1 10". In order to 207 provide multi-homed sites with equivalent functionality as it is 208 available to them using PI space, the AGGREGATE_INFO BGP attribute 209 allows the originator to specify an AS_PATH attribute to be appended 210 with the path contained in the aggregate route. This allows the 211 customer AS (AS 10) to indicate to AS 3 that the attribute comparison 212 should be performed between the explicitly advertised more-specific 213 with as-path "2 10" and an implicit more-specific path with an as- 214 path of "1 10". This implicit path is derived from the aggregate 215 prefix. 217 3. BGP AGGREGATE_INFO attribute 219 The BGP AGGREGATE_INFO attribute is a well-known, transitive 220 attribute with Type Code 129. It contains a list of one or more 221 aggregate target elements. Each aggregate target contains a 222 mandatory part, with the operational status field followed by a route 223 prefix. That may be followed by additional BGP PATH attributes that 224 apply to the specified aggregate target prefix. 226 The operational status is encoded as a 1-octect field with the 227 following values: 229 +-------+--------+-----------------------------------------------+ 230 | Value | Color | Description | 231 +-------+--------+-----------------------------------------------+ 232 | 0 | Red | No connectivity between customer and provider | 233 | 1 | Yellow | Direct connectivity unavailable | 234 | 2 | Green | Connectivity fully operational | 235 +-------+--------+-----------------------------------------------+ 237 The prefix is encoded as a 2 byte AFI [RFC1700] value, followed by a 238 variable length prefix encoded as a 1 byte prefix-length in bits and 239 the prefix itself padded to a byte boundary. This is the same 240 encoding used for NLRI in BGP UPDATE messages. 242 The prefix contained in the AGGREGATE_INFO attribute SHOULD be a 243 less-specific prefix containing all the NLRI specified in the BGP 244 UPDATE message that includes this attribute. 246 Following the route prefix, the encoding allows for one of more BGP 247 path attributes using the encoding specified the BGP [RFC4271] 248 protocol specification. An implementation MAY choose to include an 249 AS_PATH attribute in this optional element. 251 When an AS_PATH attribute is contained inside an AGGREGATE_INFO 252 attribute, the path segments that it contains shall be appended to 253 the AS_PATH of the implicit path represented by the aggregate prefix. 255 This implicit path is then compared with the best path of NLRI 256 prefix(es) included in the UPDATE message containing this attribute. 258 Example encoding for prefix 10.0/16, as-path "10": 260 Attr Flags = 0x40, Attr Code = 0x81, Attr Length = 0x0e 262 OpStatus=0x2, AFI = 0x00 0x01, Prefix Length = 0x10, Prefix Data = 263 0x0a 0x00 265 Attr Flags = 0x40, Attr Code = 0x02, Attr Length = 0x04, Data = 266 0x02 0x01 0x00 0x0a 268 In the example given above, an AS_PATH segment of "10" in the 269 aggregate-info attribute and an aggregate path with an AS_PATH of "1" 270 would result in a as-path of "1 10", of length 2. 272 When multiple aggregate target prefixes are present in a 273 AGGREGATE_INFO attribute, the most significant prefix present in the 274 Loc-Rib is used to generate the implicit path used in path selection. 276 Multiple targets can be used when prefix assignment and delegation 277 happens at more than one level. 279 As an example, a provider X may have a /16 out of which it delegates 280 to Y a specific /22 block. Y then allocates a /24 to a specific 281 multi-homed customer Z. If Y itself is using aggregation its prefix 282 may be suppressed. Where Z to originate a route with a single 283 aggregation-target (/22), that prefix would not be aggregated in 284 regions of the network where the /22 had itself be aggregated. 286 For this mechanism to behave as expected one would have to ensure 287 that if Y's prefix has been suppress then Z's has also been 288 suppressed. Otherwise if Z's prefix is present, its aggregation 289 target of Y will be ignored. 291 Since this condition cannot be guaranteed, the protocol allows the 292 originator of the more-specific prefix (Z) to include multiple 293 aggregation targets (Y and X) in its route advertisement. Whenever Y 294 is present in the Loc-Rib of BGP speaker, Y is used as source of the 295 implicit aggregation path. Otherwise X is used if present. 297 The choice of explicitly listing the aggregation targets rather than 298 automatically deriving the parent is designed to avoid situations in 299 which the less-specific is being artificially generated such as, for 300 instance, the default route. 302 4. BGP extension deployment 304 BGP speakers that support the extensions described in this document 305 SHALL use the Capability Advertisement [RFC5492] BGP extension to 306 advertise that support to its BGP peers. 308 Compliant implementations should advertise the BGP Capability Code 309 TBD. The capability data should contain a 1-byte value which is 310 interpreted as the version of this specification. It should contain 311 the value 1. 313 When a BGP route is placed in the Out-RIB for a given external BGP 314 peer and the peer in question doesn't support this capability, if the 315 path in the Loc-Rib contains the AGGREGATE_INFO attribute this should 316 result in the prefix being suppressed. If a previous path was 317 advertised to this peer that path shall be withdrawn. 319 If the peer in question is an internal BGP peer which doesn't support 320 this capability an implementation MAY choose to replace this 321 attribute with the NO_EXPORT [RFC1997] BGP community attribute, 322 rather than suppress the path. 324 This mechanism assures that a path that originated with an 325 AGGREGATE_INFO attribute is not used by a router without being 326 compared to the respective aggregate. This is intended to facilitate 327 the incremental deployment of this functionality. 329 5. Path selection criteria 331 A BGP implementation shall run its path selection algorithm 332 unmodified between all the paths for a given prefix. If the selected 333 best-path contains the BGP AGGREGATE_INFO attribute, this path shall 334 be compared with the best-path of the aggregate prefix indicated by 335 the attribute in question. 337 The AGGREGATE_INFO attribute represents an implicit path for the 338 more-specific prefix (the NLRI containing that attribute). The BGP 339 path attributes of this implicit prefix are the attributes of the 340 best-path of the aggregate prefix. If the AGGREGATE_INFO contains an 341 optional AS_PATH attribute, the AS_PATH segments in that attribute 342 shall be appended to the AS_PATH of the aggregate prefix best-path 343 before comparison. 345 When the Operational Status of the specified aggregate target is 346 "Red" the corresponding implicit path is considered to be 347 unreachable. When the Operational Status is "Yellow" the originating 348 AS of the aggregate target prefix MUST treat the implicit path as 349 unreachable also and use the more-specific. Autonomous-systems 350 further downstream MAY choose whether to ignore or use the 351 aggregation information. 353 The "Yellow" state represents that the originator of the prefix 354 believes that there is a path between the primary and backup 355 providers for the site such that this path always prefers the more- 356 specific advertisement. This is often the case if both providers 357 have a direct peering relationship. 359 When comparing the more-specific path with its implicit path 360 (represented by the aggregate), the following changes to the standard 361 path selection algorithm should be taken into account: 363 o The Origin attributes of both paths are not comparable. This is 364 step b) in the path selection algorithm and should be bypassed. 366 o If the paths in question are equal upto step d) of path selection 367 algorithm, if both paths are EBGP paths, the less-specific 368 (aggregate) should be preferred. This replaces the step in path 369 selection where the oldest EBGP path is preferred [RFC5004]. 371 o If both paths are iBGP paths, the less-specific (aggregate) should 372 be preferred in case where the paths are equal up-to the router-id 373 comparison step of path selection. 375 When the aggregate path is considered to be preferable over the more- 376 specific, the more-specific should be considered inactive and should 377 not be installed in the FIB or subsequently advertised to other 378 peers. 380 6. Network deployment 382 The objective of this document is to provide multi-homed sites with 383 the resilience to failures and limited traffic-engineering 384 capabilities without the need to recurse to PI advertisements. 386 Instead of using a PI prefix, a multi-homed site can choose to 387 address its network with PA prefix from one service provider which it 388 then advertises through a secondary provider. Or it may choose to 389 dual address its hosts and/or NAT appliances. 391 In order for a multi-homed site to achieve the required resilience it 392 should be allowed by other service providers to inject the more- 393 specifics that have been delegated to it with the BGP AGGREGATE_INFO 394 attribute. 396 The AGGREGATE_INFO attribute should only be added to a BGP path by 397 the originator of the route advertisement. This rule is intended to 398 ensure that there aren't instances of the same BGP path information 399 flowing through the Internet routing system with and without the 400 specified attribute. 402 In order to maintain the loop free properties of BGP one must ensure 403 that when suppressing a more-specific this doesn't result in traffic 404 being forwarded in a way which results in a loop. 406 For this to occur, the following conditions would be necessary: 408 A transit AS (X) prefers the more-specific route. 410 Another AS (Y) receives both aggregate and more-specific from X 411 and prefers the former. 413 Y is in the transit path for the more-specific. 415 The last condition cannot occur since Y, by definition prefers the 416 aggregate path and will not advertise the more-specific. 418 7. Acknowledgements 420 There have been several prior proposals to reduce routing information 421 used in muli-homing scenarios. For instance, using BGP communities 422 [I-D.white-bounded-longest-match] and AS hops 423 [I-D.ietf-idr-as-hopcount]. 425 The current document builds upon the previous work and proposes the 426 use of standard BGP path selection using both implicit and explicit 427 paths in order limit information to parts of the network where it is 428 useful. 430 8. Contributors 432 Central parts of the protocol operation where defined by Robert 433 Raszuk and Keyur Patel. Russ White, Enke Chen, Dave Meyer and Vince 434 Fuller provided essential input in the early stages of the proposal. 436 9. IANA Considerations 438 This memo requests IANA to allocate a BGP attribute type code value, 439 for the BGP aggregate-info attribute defined herein. It also 440 requests IANA to allocate a Capability Code according to the 441 procedures defined in RFC 5492 [RFC5492]. 443 10. Security Considerations 445 The BGP aggregate-info attribute in itself doesn't create a new 446 security threat. This attribute can only lead to the route being 447 suppressed. 449 The presence of more-specifics in the routing system makes a stronger 450 case for the usefulness of performing origin authentication of route 451 advertisements. 453 11. References 455 11.1. Normative References 457 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 458 October 1994. 460 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 461 Communities Attribute", RFC 1997, August 1996. 463 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 464 Protocol 4 (BGP-4)", RFC 4271, January 2006. 466 [RFC5004] Chen, E. and S. Sangli, "Avoid BGP Best Path Transitions 467 from One External to Another", RFC 5004, September 2007. 469 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 470 with BGP-4", RFC 5492, February 2009. 472 11.2. Informative References 474 [I-D.ietf-idr-as-hopcount] 475 Li, T., "The AS_HOPCOUNT Path Attribute", 476 draft-ietf-idr-as-hopcount-00 (work in progress), 477 December 2005. 479 [I-D.white-bounded-longest-match] 480 Hares, S., "Bounding Longer Routes to Remove TE", 481 draft-white-bounded-longest-match-02 (work in progress), 482 July 2008. 484 Authors' Addresses 486 Pedro Marques (editor) 487 Cisco Systems, Inc. 488 170 W. Tasman Dr. 489 San Jose, CA 94040 490 US 492 Phone: +1 408 853 1193 493 Email: roque@cisco.com 495 Russ White 496 Cisco Systems, Inc. 497 7025 Kit Creek Road 498 Research Triangle Park, NC 27709 499 US 501 Email: riw@cisco.com