idnits 2.17.1 draft-ietf-grow-simple-va-09.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 (June 5, 2012) is 4344 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GROW Working Group R. Raszuk 3 Internet-Draft NTT MCL 4 Intended status: Informational J. Heitz 5 Expires: December 7, 2012 Ericsson 6 A. Lo 7 Arista 8 L. Zhang 9 UCLA 10 X. Xu 11 Huawei 12 June 5, 2012 14 Simple Virtual Aggregation (S-VA) 15 draft-ietf-grow-simple-va-09.txt 17 Abstract 19 The continued growth in the Default Free Routing Table (DFRT) 20 stresses the global routing system in a number of ways. One of the 21 most costly stresses is Forwarding Information Base (FIB) size: ISPs 22 often must upgrade router hardware simply because the FIB has run out 23 of space, and router vendors must design routers that have adequate 24 FIB. 26 FIB suppression is an approach to relieving stress on the FIB by NOT 27 loading selected RIB entries into the FIB. Simple Virtual 28 Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that 29 allows any and all edge routers to shrink their RIB and FIB 30 requirements substantially and therefore increase their useful 31 lifetime. 33 S-VA does not increase FIB requirements for core routers. S-VA is 34 extremely easy to configure considerably more so than the various 35 tricks done today to extend the life of edge routers. S-VA can be 36 deployed autonomously by an ISP (cooperation between ISPs is not 37 required), and can co-exist with legacy routers in the ISP. 39 Status of this Memo 41 This Internet-Draft is submitted to IETF in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on December 7, 2012. 56 Copyright Notice 58 Copyright (c) 2012 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5 75 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 5 76 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 77 2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . 6 78 3. Deployment considerations . . . . . . . . . . . . . . . . . . 8 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 84 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 ISPs today manage constant Default Free Routing Table (DFRT) growth 90 in a number of ways. One way, of course, is for ISPs to upgrade 91 their router hardware before DFRT growth outstrips the size of the 92 FIB. This is too expensive for many ISPs. They would prefer to 93 extend the lifetime of routers whose FIBs can no longer hold the full 94 DFRT. 96 A common approach taken by lower-tier ISPs is to default route to 97 their providers. Routes to customers and peer ISPs are maintained, 98 but everything else defaults to the provider. This approach has 99 several disadvantages. First, packets to Internet destinations may 100 take longer-than-necessary AS paths. 102 This problem can be mitigated through careful configuration of 103 partial defaults, but this can require substantial configuration 104 overhead. A second problem with defaulting to providers is that the 105 ISP is no longer able to provide the full DFRT to its customers. 106 Finally, provider defaults prevents the ISP from being able to detect 107 martian packets. As a result, the ISP transmits packets that could 108 otherwise have been dropped over its expensive provider links. 110 An alternative is for the ISP to maintain full routes in its core 111 routers, but to filter routes from edge routers that do not require a 112 full DFRT. These edge routers can then default route to the core or 113 exit routers. This is often possible with edge routers that 114 interface to customer networks. The problem with this approach is 115 that it cannot be used for all edge routers. For instance, it cannot 116 be used for routers that connect to transits. It should also not be 117 used for routers that connect to customers which wish to receive the 118 full DFRT. 120 This draft describes a very simple technique, called Simple Virtual 121 Aggregation (S-VA), that allows any and all edge routers to have 122 substantially reduced FIB requirements even while still advertising 123 and receiving the full DFRT over BGP. The basic idea is as follows. 124 Core routers in the ISP maintain the full DFRT in the FIB and RIB. 125 Edge routers maintain the full DFRT in the BGP protocol RIB, but 126 suppress certain routes from being installed in RIB and FIB tables. 127 Edge routers may install a default route to core routers, to ABRs 128 which are installed on the Point of Presence (POP) to core boundary 129 or to the ASBR routers. 131 S-VA requires no changes to BGP and no changes to any choice of 132 forwarding mechanisms in routers. Configuration is extremely simple: 133 S-VA must be enabled on the edge router which needs to save its RIB 134 and FIB space. In the same time operator must inject into his intra- 135 domain routing a new prefix further called virtual aggregate (VA- 136 prefix) which will be used as the aggregate forwarding reference by 137 the edge routers performing S-VA. Everything else is automatic. 138 ISPs can deploy FIB suppression autonomously and with no coordination 139 with neighbor ASes. 141 In configurations where BGP routes are used to resolve other routes 142 or where BGP routes are redistributed to other protocols which both 143 happen via RIB simple-va can rather then suppressing routes before 144 they are installed in global RIB flag them as "suppress eligible". 145 That will allow for seamless route resolution or redistribution while 146 in the same time FIB size will continue to be limited as previously 147 flagged routes will not be send from RIB to FIB. 149 1.1. Scope of this Document 151 The scope of this document is limited to Intra-domain S-VA operation. 152 In other words, the case where a single ISP autonomously operates 153 S-VA internally without any coordination with neighboring ISPs. 155 Note that this document assumes that the S-VA "domain" (i.e. the unit 156 of autonomy) is the AS (that is, different ASes run S-VA 157 independently and without coordination). For the remainder of this 158 document, the terms ISP, AS, and domain are used interchangeably. 160 This document applies equally to IPv4 and IPv6 both unicast and 161 multicast address families. 163 S-VA may operate with a mix of upgraded routers and legacy routers. 164 There are no topological restrictions placed on the mix of routers. 165 S-VA functionality is local to the router on which it is enabled and 166 routing correctness is guaranteed. 168 Note that S-VA is a greatly simplified variant of "full VA" 169 [I-D.ietf-grow-va]. With full VA, all routers (core or otherwise) 170 can have reduced FIBs. However, full VA requires substantial new 171 configuration and operational complexity compared to S-VA. Full VA 172 also requires the use of MPLS LSPs between all routers. Note that 173 S-VA was formerly specified in [I-D.ietf-grow-va]. It has been moved 174 to this separate draft to simplify its understanding. 176 1.2. Requirements notation 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 1.3. Terminology 184 RIB/FIB-Installing Router (FIR): An router that does not suppress 185 any routes, and advertises itself as a default route for 0/0. 186 Typically a core router, POP to core boundary router or an ASBR 187 would be configured as an FIR. 188 RIB/FIB-Suppressing Router (FSR): An S-VA router that installs a 189 route to 0/0, and may suppress other routes. Typically an edge 190 router would be configured as an FSR. 191 Install and Suppress: The terms "install" and "suppress" are used to 192 describe whether a protocol local RIB entry has been loaded or not 193 loaded into the global RIB and FIB. In other words, the phrase 194 "install a route" means "install a route into the global RIB and 195 FIB", and the phrase "suppress a route" means "do not install a 196 route from BGP into the global RIB and FIB". 197 Legacy Router: A router that does not run S-VA, and has no knowledge 198 of S-VA. 199 Global Routing Information Base (RIB): The term global RIB is used 200 to indicate the router's main routing information base. That RIB 201 is normally used to populate FIB tables of the router. It needs 202 to be highlighted that unless FIB compression is used global RIB 203 and FIB tables are in sync. 204 Local/Protocol Routing Information Base (loc-RIB): The term local 205 RIB is used to indicate the protocol's table where product of SPF 206 or BGP best path selection is kept before being installed in 207 global RIB. For example, in some protocol implementations BGP 208 loc-RIB can be further divided into Adj-RIBs-In, the Loc-RIB, and 209 the Adj-RIBs-Out. 211 2. Operation of S-VA 213 There are three types of routers in S-VA, FIB-Installing routers 214 (FIR), FIB-Suppressing routers (FSR), and optionally legacy routers. 215 While any router can be an FIR or an FSR (there are no topology 216 constraints), the most simple form of deployment is for AS border or 217 POP border routers to be configured as FIRs, and for customer facing 218 edge routers respectively in the AS or in the POP to be configured as 219 FSRs. 221 There are two basic network deployment scenarios for S-VA - with and 222 without presence of a default route. In both cases simple VA 223 operates in an identical way however when default route is found and 224 is eligible to become a less specific prefix by router's 225 configuration the S-VA may use it. That should not prevent detection 226 of any other potential prefix with different next hop as the next hop 227 of default route. 229 In the event of FIRs originating a default BGP route to NLRI 0/0 230 [RFC4271]. The ORIGIN is set to INCOMPLETE (value 2) and the BGP 231 NEXT_HOP is set to match the other BGP routes which are also 232 advertised by said FIR. The ATOMIC_AGGREGATE and AGGREGATOR 233 attributes are not included. The FIR MUST attach a NO_EXPORT 234 Community Attribute [RFC1997] to the default route. 236 FIRs should not FIB-suppress any routes. They may, however, still 237 use some form of local FIB compression algorithm if deemed necessary. 239 FSRs must detect the VA prefix or prefixes (including 0/0) and 240 install it both in loc-RIB, RIB and FIB. Following that FSR may 241 suppress any more specific routes which carry the same next hop as 242 the VA prefix. To guarantee semantical correctness FSR by default 243 should also be able to detect installation of not matching next hop 244 route and reinstall all the more specifics which were previously 245 eligible for suppression to maintain semantical forwarding 246 correctness. 248 Generally, any more specific route which carries the same next hop as 249 the VA-prefix is eligible for suppression. However, provided that 250 there was at least one less specific prefix with different next hop 251 between VA-prefix and the prefixes which got suppressed then all 252 previously suppressed prefixes must be reinstalled. 254 Similarly when IBGP multipath is enabled and when multiple VA 255 prefixes are detected which are multipath candidates under given 256 network condition only those more specific prefixes are subject to 257 suppression which have the identical set of next hops as multipath 258 set of VA prefixes. 260 We illustrate the expected behavior on the figure below. This figure 261 shows an autonomous system with a FIR FIR1 and an FSR FSR1. FSR1 is 262 an ASBR and is connected to two remote ASBRs, EP1 and EP2. 264 +------------------------------------------+ 265 | Autonomous System | +----+ 266 | | |EP1 | 267 | /---+---| | 268 | To ----\ +----+ +----+ / | +----+ 269 | Other \|FIR1|----------|FSR1|/ | 270 |Routers /| | | |\ | 271 | ----/ +----+ +----+ \ | +----+ 272 | \---+---|EP2 | 273 | | | | 274 | | +----+ 275 +------------------------------------------+ 277 Suppose that FSR1 has been enabled to perform S-VA. Originally it 278 receives all routes from FIR1 (doing next hop self) as well as 279 directly connected EBGP peers EP1 and EP2. FIR1 now will advertise a 280 VA prefix 0/0 with next hop set to himself. That will trigger 281 detection of such prefix on FSR1 and suppression all routes which 282 have the same next hop as VA prefix and which otherwise would be 283 installed in RIB and FIB. However it needs to be observed that FSR1 284 will not suppress any EBGP routes received from his peers EP1 and EP2 285 due to next hop being different from the one assigned to VA-prefix. 287 3. Deployment considerations 289 The simplest deployment model of S-VA is its use within the POP. In 290 such model the POP to core boundary routers (usually RRs in the data 291 path) would act as FIRs and would inject VA-prefix 0/0 to all of its 292 clients within the POP. In such model of operation an observation 293 can be made that such ABRs do have full routing knowledge and client 294 to ABR distance is negligible as compared with client to intra-domain 295 exit distance. 297 Therefore under the above intra POP S-VA deployment model clients can 298 be configured that even in the event of lack of ABR to ABR 299 advertisement symmetry there is still no need to monitor if more 300 specific unsuppressed route would cover suppressed one. Thus in this 301 particular deployment model there is no need to detect and reinstall 302 the previously suppressed ones. 304 Another deployment consideration should be given to networks which 305 may utilize route reflection. In the event of enabling IBGP 306 multipath a special care must be taken that both outbound prefixes as 307 well as VA-prefixes would pass via said route reflectors to their 308 clients. 310 In order to address the above aspects the following solutions could 311 be considered: 313 - Use of intra-POP S-VA 314 - Full mesh Small or medium side networks where S-VA can be deployed 315 are normally fully meshed and do not use route reflection. It 316 also needs to pointed out that some large networks are also fully 317 meshed today. 318 - Use of add-paths Use of add-paths new BGP encoding will allow to 319 distribute more then one overall best path from RR to each client. 321 - Alternate advertisement of VA-prefix S-VA prefix does not need to 322 be advertised in BGP. The BGP suppression will happen as long as 323 we configure the S-VA with next hop(s) and implementation verifies 324 that such VA-prefix is installed in the RIB and FIB. 326 BGP routes may be used to resolve nexthops for static routes or other 327 BGP routes. Because the default route does not imply reachability of 328 any destination, a router can be configured not to resolve nexthops 329 using the default route. In this case, simple-va should not suppress 330 a route that may be used to resolve a nexthop for another route. 332 Selected BGP routes in the RIB may be redistributed to other 333 protocols. If they no longer exist in the RIB, they will not be 334 redistributed. This is especially important when the conditional 335 redistribution is taking place based on the length of the prefix, 336 community value etc .. In those cases where redistribution policy is 337 in place simple-va code should refrain from suppressing prefixes 338 matching such policy. 340 A router may originate a network route or an aggregate route into 341 BGP. Some addresses covered by such a route may not exist. If this 342 router were to receive a packet for an unreachable address within an 343 originated route, it must not send that packet to the default route. 344 There are several ways to achieve this. One is to have the FIR 345 aggregate the routes instead of the FSR. Another is to install a 346 blackhole route for the nonexistent addresses on the originating 347 router. This issue is not specific to simple-va, but applicable to 348 the general use of default routes. 350 4. IANA Considerations 352 There are no IANA considerations. 354 5. Security Considerations 356 The authors are not aware of any new security considerations due to 357 S-VA. 359 6. Acknowledgements 361 The concept for Virtual Aggregation comes from Paul Francis. In this 362 document authors only simplified some aspects of its behavior to 363 allow simpler adoption by some operators. 365 Authors would like to thank Clarence Filsfils, Nick Hilliard, S. 367 Moonesamy and Tom Petch for their review and valuable input. 369 7. References 371 7.1. Normative References 373 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 374 Communities Attribute", RFC 1997, August 1996. 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 380 Protocol 4 (BGP-4)", RFC 4271, January 2006. 382 7.2. Informative References 384 [I-D.ietf-grow-va] 385 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 386 L. Zhang, "FIB Suppression with Virtual Aggregation", 387 draft-ietf-grow-va-06 (work in progress), December 2011. 389 Authors' Addresses 391 Robert Raszuk 392 NTT MCL 393 101 S Ellsworth Avenue Suite 350 394 San Mateo, CA 94401 395 US 397 Email: robert@raszuk.net 399 Jakob Heitz 400 Ericsson 401 300 Holger Way 402 San Jose, CA 95135 403 USA 405 Phone: 406 Email: jakob.heitz@ericsson.com 407 Alton Lo 408 Arista Networks 409 5470 Great America Parkway 410 Santa Clara, CA 95054 411 USA 413 Phone: 414 Email: altonlo@aristanetworks.com 416 Lixia Zhang 417 UCLA 418 3713 Boelter Hall 419 Los Angeles, CA 90095 420 US 422 Phone: 423 Email: lixia@cs.ucla.edu 425 Xiaohu Xu 426 Huawei Technologies 427 No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District 428 Beijing, Beijing 100085 429 P.R.China 431 Phone: +86 10 82836073 432 Email: xuxh@huawei.com