idnits 2.17.1 draft-white-grow-overlapping-routes-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 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 (July 9, 2012) is 4302 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-idr-custom-decision-01 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 Verisign 4 Intended status: Experimental A. Retana 5 Expires: January 10, 2013 Hewlett-Packard Co. 6 S. Hares 7 Hauwei 8 July 9, 2012 10 Filtering of Overlapping Routes 11 draft-white-grow-overlapping-routes-00 13 Abstract 15 This document proposes a mechanism to remove a prefix when it 16 overlaps with a functionally equivalent shorter prefix. The proposed 17 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 January 10, 2013. 36 Copyright Notice 38 Copyright (c) 2012 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 . . . . . . . . . . . . . 3 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 Automatic Filtering of TE Routes . . . . . . . . 5 63 5. Benefits and Implications . . . . . . . . . . . . . . . . . . . 6 64 5.1. Advantages to the Service Provider . . . . . . . . . . . . 6 65 5.2. Advantages to the Customer . . . . . . . . . . . . . . . . 6 66 5.3. Advantages to the Internet . . . . . . . . . . . . . . . . 6 67 5.4. Implications for Router processing . . . . . . . . . . . . 7 68 5.5. Implications for Traffic engineering . . . . . . . . . . . 7 69 5.6. Implications for Convergence Time . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 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 are often less stable than the covering routes 96 they are paired with. Overall, then, it is desirable to remove 97 overlapping routes from the global routing table where possible. 99 However, given the importance of an autonomous system's ability to 100 steer traffic into specific entry points, simply removing the longer 101 prefixes in a longer prefix (overlapping)/shorter prefix (covering) 102 pair of routes isn't a viable solution. 104 This document proposes a mechanism to detect routes that have been 105 injected into the global default free zone, and to remove routes that 106 are no longer useful for steering traffic towards a specific entry 107 point in a particular AS. Removing these routes would reduce the 108 global table in size, and reduce the instability of the global table, 109 while removing no capabilities, nor increasing the average path 110 length. The mechanism proposed is simple to implement, requiring no 111 changes to the BGP [RFC4271] protocol either in packet format or in 112 the decision process. 114 2. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 3. Overlapping Route Filtering Mechanism 122 The handling of overlapping prefixes received from an external peer 123 can be broken down into four parts: marking overlapping routes, 124 preferring marked routes, handling marked routes within the AS, and 125 handling marked routes at the AS exit point. 127 The initial step in successfully filtering overlapping routes is to 128 identify and mark them. This document proposes the use of a BGP 129 community called BOUNDED for that purpose. Because the operation 130 suggested takes place inside an Autonomous System (AS), then any 131 locally assigned community can be used. 133 The term BOUNDED is used to refer to a locally assigned community 134 used to mark overlapping routes, and to these marked routes as well. 136 3.1. Marking Overlapping Routes 138 As each prefix is received by a BGP speaker from an external peer, it 139 is evaluated in the light of other prefixes already received. If two 140 prefixes overlap in space (such as 192.0.2.0/24 and 192.0.2.128/25), 141 the longer prefix SHOULD be BOUNDED. 143 A BGP speaker MAY also choose to check the AS_PATH attribute length 144 and contents before marking a prefix as BOUNDED. 146 3.2. Preferring Marked Routes 148 Since the same overlapping route may be received at several peering 149 points along the edge of the AS, and the covering route may not be 150 present at each of these points, BOUNDED routes SHOULD be preferred 151 over unmarked routes for overlapping routes to be properly handled. 152 A router which marks an overlapping route SHOULD also use one of the 153 two mechanisms described here to insure the marked route is preferred 154 throughout the AS. 156 Only one method described in this section SHOULD be deployed in any 157 given AS. 159 3.2.1. Using a Cost Community 161 The RECOMMENDED method for preferring BOUNDED routes is to use a Cost 162 Community [I-D.ietf-idr-custom-decision] with the Point of Insertion 163 set to ABSOLUTE_VALUE. This mechanism leaves all existing local 164 policy controls in place within the AS. 166 If this method is used, only the BOUNDED routes need to be tagged 167 using a lower than default Cost, as routes without a Cost Community 168 are considered to have the default value. 170 3.2.2. Using the Local Preference 172 An alternate mechanism which may be used to prefer BOUNDED routes is 173 to set their Local Preference to some number higher than the normal 174 standard policy settings for a particular prefix. It's not important 175 that any particular BOUNDED route win over any other one; so simply 176 adding a small amount to the normal Local Preference, as dictated by 177 local policy, will ensure a BOUNDED route will always win over an 178 unmarked route, so only these routes reach the outbound edge of the 179 AS. 181 3.3. Handling Marked Routes Within the AS 183 Routes marked with the BOUNDED community MAY not be installed in the 184 local RIB of routers within the AS. This optional step will reduce 185 local RIB and forwarding table usage and volatility within the AS. 187 3.4. Handling Marked Routes at the Outbound Edge 189 Routes marked with the BOUNDED community SHOULD NOT be advertised to 190 external peers. If they are advertised, they SHOULD then be marked 191 with the NO_EXPORT community. 193 4. An Example of Automatic Filtering of TE Routes 195 Assume the following configuration of autonomous systems: 196 ( ) 197 /-------( AS2 )--------\ 198 ( ) / ( ) \ ( ) ( ) 199 ( AS1 ) ( AS4 )-----( AS5 ) 200 ( ) \ ( ) / ( ) ( ) 201 \-------( AS3 )--------/ 202 ( ) 204 o AS1 is advertising 192.0.2.128/25 to both AS2 and AS3. 206 o AS2 is advertising both 192.0.2.128/25 and 192.0.2.0/24 into AS4. 208 o AS3 is advertising 192.0.2.128/25 into AS4 210 o Each BGP connection (session) is handled by a seperate router 211 within each AS (for instance, AS4 peers with AS2 and AS3 on a 212 seperate routers). 214 When the router in AS4 peering with AS2 receives both the 215 192.0.2.128/25 and the 192.0.2.0/24 prefixes, it will mark 216 192.0.2.128/25 as BOUNDED, and set a Cost Community (as described in 217 Section 3.2.1) so the marked overlapping route is preferred over 218 unmarked routes within AS4. 220 The border router between AS4 and AS3 will receive the longer prefix 221 from AS3, and the preferred BOUNDED overlapping route through iBGP. 222 It will prefer the marked route, so the unmarked route towards 223 192.0.2.128/25 will not be advertised throughout AS4. 225 If the link between AS1 and AS2 fails, the longer length prefix will 226 be withdrawn from AS2, and thus the peering point between AS2 and AS4 227 will no longer have an overlapping set of prefixes. Within AS4, the 228 border router which peers with AS2 will cease advertising the 229 192.0.2.128/25 prefix, which allows the AS3/AS4 border router to 230 begin advertising it into AS4, and through AS4 into AS5, restoring 231 connectivity to AS1. 233 5. Benefits and Implications 235 The benefits and implications associated with this proposal are 236 discussed in the sections below. The text references the sample 237 network in Section 4. 239 5.1. Advantages to the Service Provider 241 AS4, in each of the situations, reduces the number of prefixes 242 advertised to transit peering autonomous systems by the number of 243 longer prefixes that overlap with aggregates of those prefixes, so 244 that AS5 receives fewer total routes, and a more stable routing 245 table. While one copy of the prefix continues to be carried through 246 the autonomous system, this entry can be removed from the local 247 forwarding table. 249 5.2. Advantages to the Customer 251 In the example given here, the customer is represented as AS1. The 252 customer will continue to receive some amount of traffic over both 253 peering sessions, and dual homing through two Service Providers is 254 still effective. If the customer's primary link fails, the alternate 255 link through AS3 will take over receiving all inbound traffic 256 automatically. 258 5.3. Advantages to the Internet 260 Beyond the second AS hop, aggregation is preserved in all cases. 261 While this would not reduce the backbone routing table by the 262 dramatic amounts that other methods might, the advantages to the 263 community are large, and the risk to individual autonomous systems 264 and providers is small. 266 5.4. Implications for Router processing 268 This proposal requires all BGP speakers to perform an additional 269 check on receiving a route, checking the route against existing 270 routes for overlapping coverage of a set of reachable destinations. 271 This additional work, in terms of processing requirements, should be 272 easily offset by the overall savings in processing through the 273 reduction of the global default free zone table size, and the 274 additional stability in the routing table due to the removal of 275 longer length prefixes. 277 5.5. Implications for Traffic engineering 279 The implementation of filtering overlapping routes as described in 280 this document risks magnifying or removing the effect of certain 281 widely deployed traffic engineering methods. If, for example, an AS 282 chose to prepend its own route to an announcement in order to alter 283 the preference for that route, a BGP neighbor using automatic 284 filtering of overlapping routes might now see that route as eligible 285 for discard in favor of an aggregate. It should be fairly easy to 286 define a local policy to work around that particular problem. 288 5.6. Implications for Convergence Time 290 If the route to the AS providing the route to the aggregate should be 291 lost, the more-specific must propagate into the ASes which had 292 formerly heard only the aggregate. This increases convergence time 293 and may create situations in which reachability is temporarily 294 compromised. Unlike the filter case, however, normal BGP behavior 295 should restore reachability without changes to the router 296 configuration. 298 6. Security Considerations 300 This document presents a mechanism for an autonomous system to mark 301 and filter overlapping prefixes. Note that the result if this 302 operation is akin to the implementation of local route filtering at 303 an AS boundary. As such, this document doesn't introduce any new 304 security risks. 306 7. IANA Considerations 308 This document has no IANA actions. 310 8. Acknowledgements 312 Cengiz Alaentinoglu, Daniel Walton, David Ball, Ted Hardie, Jeff 313 Hass, and Barry Greene gave valuable comments on this document. 315 9. References 317 9.1. Normative References 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, March 1997. 322 9.2. Informative References 324 [I-D.ietf-idr-custom-decision] 325 Retana, A. and R. White, "BGP Custom Decision Process", 326 draft-ietf-idr-custom-decision-01 (work in progress), 327 May 2012. 329 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 330 Protocol 4 (BGP-4)", RFC 4271, January 2006. 332 Authors' Addresses 334 Russ White 335 Verisign 336 12061 Bluemont Way 337 Reston, VA 20190 338 USA 340 Email: riwhite@verisign.com 342 Alvaro Retana 343 Hewlett-Packard Co. 344 2610 Wycliff Road 345 Raleigh, NC 27607 346 USA 348 Email: alvaro.retana@hp.com 349 Susan Hares 350 Hauwei 351 USA 353 Email: skh@ndzh.com