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