idnits 2.17.1 draft-white-grow-overlapping-routes-02.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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2013) is 3843 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-idr-custom-decision-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. White 3 Internet-Draft 4 Intended status: Informational A. Retana 5 Expires: April 20, 2014 Cisco Systems, Inc. 6 S. Hares 7 ADARA 8 October 17, 2013 10 Filtering of Overlapping Routes 11 draft-white-grow-overlapping-routes-02 13 Abstract 15 This document proposes an optional mechanism to remove a prefix when 16 it overlaps with a functionally equivalent shorter prefix. The 17 proposed mechanism does not require any changes to the BGP protocol. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 20, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 55 3. Overlapping Route Filtering Mechanism . . . . . . . . . . . . . 4 56 3.1. Marking Overlapping Routes . . . . . . . . . . . . . . . . 4 57 3.2. Preferring Marked Routes . . . . . . . . . . . . . . . . . 4 58 3.2.1. Using a Cost Community . . . . . . . . . . . . . . . . 4 59 3.2.2. Using the Local Preference . . . . . . . . . . . . . . 5 60 3.3. Handling Marked Routes Within the AS . . . . . . . . . . . 5 61 3.4. Handling Marked Routes at the Outbound Edge . . . . . . . . 5 62 4. An Example of Filtering Overlapping Routes . . . . . . . . . . 5 63 5. Operational Considerations . . . . . . . . . . . . . . . . . . 6 64 5.1. Advantages to the Service Provider . . . . . . . . . . . . 6 65 5.2. Implications for Router processing . . . . . . . . . . . . 7 66 5.3. Implications for Convergence Time . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 73 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 8 74 A.1. Changes between the -00 and -01 versions. . . . . . . . . . 8 75 A.2. Changes between the -01 and -02 versions . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 One cause of the growth of the global Internet's default free zone 81 table size is overlapping routes injected into the routing system to 82 steer traffic among various entry points into a network. Because 83 padding AS Path lengths can only steer inbound traffic in a very 84 small set of cases, and other mechanisms used to steer traffic to a 85 particular inbound point are ineffective when multiple upstream 86 providers are in use, advertising longer prefixes is often the only 87 possible way for an AS to steer traffic into specific entry points 88 along its edge. 90 These longer prefix routes, called overlapping routes in this 91 document, are often advertised along with a shorter prefix route, 92 called a covering route, in order to ensure connectivity in the case 93 of link or device failures. Overlapping routes not only add to the 94 load on routers in the Internet core by simply expanding the table 95 size; these routes may be less stable than the covering routes they 96 are paired with. 98 Given the importance of an autonomous system's ability to steer 99 traffic into specific entry points, simply removing the longer 100 prefixes in a longer prefix (overlapping)/shorter prefix (covering) 101 pair of routes isn't a viable solution. 103 This document proposes an optional mechanism to remove overlapping 104 routes that are no longer useful for steering traffic towards a 105 specific entry point in a particular AS. Removing these routes would 106 reduce the global table in size, and reduce its instability, while 107 removing no capabilities, nor increasing the average path length. 109 The mechanism proposed is simple to implement, requiring no changes 110 to BGP [RFC4271] either in packet format or in the decision process. 111 The removal described in this document is akin to filtering, not to 112 route aggregation. 114 The intent of the mechanism is for it to be used based on local 115 decisions and policies, not on an Internet-wide fashion. It is 116 assumed that network operators using this mechanism have an incentive 117 to do so. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. Overlapping Route Filtering Mechanism 127 The handling of overlapping prefixes received from an external peer 128 can be broken down into four parts: marking overlapping routes, 129 preferring marked routes, handling marked routes within the AS, and 130 handling marked routes at the AS exit point. 132 The initial step in successfully filtering overlapping routes is to 133 identify and mark them. This document proposes the use of a BGP 134 community called BOUNDED for that purpose. Because the operation 135 suggested takes place inside an Autonomous System (AS), then any 136 locally assigned community can be used. 138 The term BOUNDED is used to refer to a locally assigned community 139 used to mark overlapping routes, and to these marked routes as well. 141 3.1. Marking Overlapping Routes 143 As each prefix is received by a BGP speaker from an external peer, it 144 is evaluated in the light of other prefixes already received. If two 145 prefixes overlap in space (such as 192.0.2.0/24 and 192.0.2.128/25), 146 the longer prefix SHOULD be BOUNDED if it fully overlaps the covering 147 prefix and it is the best path to the destination. 149 An overlapping prefix is said to fully overlap the corresponding 150 covering prefix if both have identical AS_PATH attributes (both in 151 length and contents) and the same NEXT_HOP. 153 3.2. Preferring Marked Routes 155 Since the same overlapping route may be received at several peering 156 points along the edge of the AS, and the covering route may not be 157 present at each of these points, BOUNDED routes should be preferred 158 over unmarked routes for overlapping routes to be properly handled. 159 A router which marks an overlapping route should also use one of the 160 two mechanisms described here to insure the marked route is preferred 161 throughout the AS. 163 Only one method described in this section SHOULD be deployed in any 164 given AS. 166 3.2.1. Using a Cost Community 168 The recommended method for preferring BOUNDED routes is to use a Cost 169 Community [I-D.ietf-idr-custom-decision] with the Point of Insertion 170 set to ABSOLUTE_VALUE. This mechanism leaves all existing local 171 policy controls in place within the AS. 173 If this method is used, only the BOUNDED routes need to be tagged 174 using a lower than default Cost, as routes without a Cost Community 175 are considered to have the default value. 177 3.2.2. Using the Local Preference 179 An alternate mechanism which may be used to prefer BOUNDED routes is 180 to set their Local Preference to some number higher than the normal 181 standard policy settings for a particular prefix. It's not important 182 that any particular BOUNDED route win over any other one; so simply 183 adding a small amount to the normal Local Preference, as dictated by 184 local policy, will ensure a BOUNDED route will always win over an 185 unmarked route, so only these routes reach the outbound edge of the 186 AS. 188 3.3. Handling Marked Routes Within the AS 190 Routes marked with the BOUNDED community MAY not be installed in the 191 local RIB of routers within the AS. This optional step will reduce 192 local RIB and forwarding table usage and volatility within the AS. 194 3.4. Handling Marked Routes at the Outbound Edge 196 Routes marked with the BOUNDED community SHOULD NOT be advertised to 197 external peers. If they are advertised, they SHOULD then be marked 198 with the NO_EXPORT community. 200 4. An Example of Filtering Overlapping Routes 202 Assume the following configuration of autonomous systems: 204 ( ) 205 /-------( AS2 )--------\ 206 ( ) / ( ) \ ( ) ( ) 207 ( AS1 ) ( AS4 )-----( AS5 ) 208 ( ) \ ( ) / ( ) ( ) 209 \-------( AS3 )--------/ 210 ( ) 212 o AS1 is advertising 192.0.2.128/25 to both AS2 and AS3. 214 o AS2 is advertising both 192.0.2.128/25 and 192.0.2.0/24 into AS4. 216 o AS3 is advertising 192.0.2.128/25 into AS4 218 o Each BGP connection (session) is handled by a separate router 219 within each AS (for instance, AS4 peers with AS2 and AS3 on 220 separate routers). 222 When the router in AS4 peering with AS2 receives both the 223 192.0.2.128/25 and the 192.0.2.0/24 prefixes, it will mark 224 192.0.2.128/25 as BOUNDED, and set a Cost Community (as described in 225 Section 3.2.1) so the marked overlapping route is preferred over 226 unmarked routes within AS4. 228 The border router between AS4 and AS3 will receive the longer prefix 229 from AS3, and the preferred BOUNDED overlapping route through iBGP. 230 It will prefer the marked route, so the unmarked route towards 231 192.0.2.128/25 will not be advertised throughout AS4. 233 If the link between AS1 and AS2 fails, the longer length prefix will 234 be withdrawn from AS2, and thus the peering point between AS2 and AS4 235 will no longer have an overlapping set of prefixes. Within AS4, the 236 border router which peers with AS2 will cease advertising the 237 192.0.2.128/25 prefix, which allows the AS3/AS4 border router to 238 begin advertising it into AS4, and through AS4 into AS5, restoring 239 connectivity to AS1. 241 5. Operational Considerations 243 The intent of the mechanism described in this document is for it to 244 be used based on local policies, not on an Internet-wide fashion. It 245 is assumed that network operators using this mechanism have an 246 incentive to do so. 248 The practice of filtering exists today on the Internet. While there 249 may be local benefits to applying manual filters and/or the mechanism 250 specified in this document, the operator should be aware of the 251 impact it may have on neighboring autonomous systems' policies 252 [I-D.cardona-filtering-threats]. 254 The benefits and implications associated with this proposal are 255 discussed in the sections below. The text references the sample 256 network in Section 4. 258 5.1. Advantages to the Service Provider 260 AS4, in each of the situations, reduces the number of prefixes 261 advertised to transit peering autonomous systems by the number of 262 longer prefixes that overlap with aggregates of those prefixes, so 263 that AS5 receives fewer total routes, and a more stable routing 264 table. While one copy of the prefix continues to be carried through 265 the autonomous system, this entry can be removed from the local 266 forwarding table. 268 5.2. Implications for Router processing 270 This proposal requires a BGP speaker to perform an additional check 271 on receiving a route, checking the route against existing routes for 272 overlapping coverage of a set of reachable destinations. This 273 additional work, in terms of processing requirements, should be 274 easily offset by the overall savings in processing through the 275 reduction of the forwarding table size, and the additional stability 276 in the routing table due to the removal of longer length prefixes. 278 5.3. Implications for Convergence Time 280 If the route to the AS providing the route to the covering route 281 should be lost, the overlapping route must now propagate into the 282 autonomous systems which had formerly received only the covering 283 route. This behavior increases convergence time and may create 284 situations in which reachability is temporarily compromised. Unlike 285 the case where manual filters are used, normal BGP behavior should 286 restore reachability without changes to the router configuration. 288 6. Security Considerations 290 This document presents a mechanism for an autonomous system to mark 291 and filter overlapping prefixes. Note that the result of this 292 operation is akin to the implementation of local route filtering at 293 an AS boundary. As such, this document doesn't introduce any new 294 security risks. 296 7. IANA Considerations 298 This document has no IANA actions. 300 8. Acknowledgements 302 Cengiz Alaentinoglu, Daniel Walton, David Ball, Ted Hardie, Jeff 303 Hass, Barry Greene, Bill Herrin and Robert Raszuk gave valuable 304 comments on this document. 306 9. References 308 9.1. Normative References 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 9.2. Informative References 315 [I-D.cardona-filtering-threats] 316 Cardona, C. and P. Francois, "Making BGP filtering a 317 habit: Impact on policies", 318 draft-cardona-filtering-threats-02 (work in progress), 319 July 2013. 321 [I-D.ietf-idr-custom-decision] 322 Retana, A. and R. White, "BGP Custom Decision Process", 323 draft-ietf-idr-custom-decision-03 (work in progress), 324 May 2013. 326 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 327 Protocol 4 (BGP-4)", RFC 4271, January 2006. 329 Appendix A. Change Log 331 A.1. Changes between the -00 and -01 versions. 333 o Updated authors' contact information. 335 o Changed intended status to Informational. 337 o General editorial changes. 339 o Clarified the intent of the draft in several places. 341 o Clarified when a route should be marked (3.1). 343 o Edited the operational considerations section. 345 o Updated ACKs. 347 A.2. Changes between the -01 and -02 versions 349 o Updated authors' contact information. 351 o General editorial changes. 353 o Refined the text about marking routes. 355 Authors' Addresses 357 Russ White 359 Email: russw@riw.us 361 Alvaro Retana 362 Cisco Systems, Inc. 363 7025 Kit Creek Rd. 364 Research Triangle Park, NC 27709 365 USA 367 Email: aretana@cisco.com 369 Susan Hares 370 ADARA 372 Email: shares@ndzh.com