idnits 2.17.1 draft-ietf-grow-va-05.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The overall semantics of VPs, however, are slightly different from those of real prefixes. Without VA, when a router originates a route for a (real) prefix, the expectation is that the addresses within the prefix are within the originating AS (or a customer of the AS). For VPs, this is not the case. APRs originate VPs whose sub-prefixes exist in different ASes. Because of this, VPs MUST not be advertised across AS boundaries. This is done with NO_EXPORT Communities Attribute (Section 3.2.3). -- The document date (July 1, 2011) is 4682 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-grow-simple-va' is defined on line 962, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-grow-va-gre' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-grow-va-mpls' is defined on line 973, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-grow-va-mpls-innerlabel' is defined on line 978, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-12) exists of draft-ietf-grow-simple-va-00 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Francis 3 Internet-Draft MPI-SWS 4 Intended status: Informational X. Xu 5 Expires: January 2, 2012 Huawei 6 H. Ballani 7 Cornell U. 8 D. Jen 9 UCLA 10 R. Raszuk 11 Cisco 12 L. Zhang 13 UCLA 14 July 1, 2011 16 FIB Suppression with Virtual Aggregation 17 draft-ietf-grow-va-05.txt 19 Abstract 21 The continued growth in the Default Free Routing Table (DFRT) 22 stresses the global routing system in a number of ways. One of the 23 most costly stresses is FIB size: ISPs often must upgrade router 24 hardware simply because the FIB has run out of space, and router 25 vendors must design routers that have adequate FIB. FIB suppression 26 is an approach to relieving stress on the FIB by not loading selected 27 RIB entries into the FIB. Virtual Aggregation (VA) allows ISPs to 28 shrink the FIBs of any and all routers, easily by an order of 29 magnitude with negligible increase in path length and load. FIB 30 suppression can be deployed autonomously by an ISP without requiring 31 cooperation between adjacent ISPs, and can co-exist with legacy 32 routers in the ISP. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 2, 2012. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5 69 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 5 70 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Overview of Virtual Aggregation (VA) . . . . . . . . . . . . . 6 72 2.1. Mix of Legacy and VA Routers . . . . . . . . . . . . . . . 9 73 2.2. Summary of Tunnels and Paths . . . . . . . . . . . . . . . 9 74 3. Specification of VA . . . . . . . . . . . . . . . . . . . . . 11 75 3.1. Legacy Routers . . . . . . . . . . . . . . . . . . . . . . 11 76 3.2. Advertising and Handling Virtual Prefixes (VP) . . . . . . 12 77 3.2.1. Distinguishing VPs from Sub-prefixes . . . . . . . . . 12 78 3.2.2. Limitations on Virtual Prefixes . . . . . . . . . . . 12 79 3.2.3. Aggregation Point Routers (APR) . . . . . . . . . . . 13 80 3.2.4. Non-APR Routers . . . . . . . . . . . . . . . . . . . 14 81 3.2.5. Adding and deleting VPs . . . . . . . . . . . . . . . 14 82 3.3. Border VA Routers . . . . . . . . . . . . . . . . . . . . 15 83 3.4. Advertising and Handling Sub-Prefixes . . . . . . . . . . 15 84 3.5. Suppressing FIB Sub-prefix Routes . . . . . . . . . . . . 16 85 3.5.1. Selecting Popular Prefixes . . . . . . . . . . . . . . 16 86 3.6. New Configuration . . . . . . . . . . . . . . . . . . . . 17 87 3.7. Interaction with Traffic Engineering . . . . . . . . . . . 18 88 4. Usage of MPLS Tunnels . . . . . . . . . . . . . . . . . . . . 19 89 4.1. Usage of Inner Label . . . . . . . . . . . . . . . . . . . 19 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 92 6.1. Properly Configured VA . . . . . . . . . . . . . . . . . . 20 93 6.2. Mis-configured VA . . . . . . . . . . . . . . . . . . . . 21 94 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 97 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 100 1. Introduction 102 ISPs today manage constant DFRT growth in a number of ways. One way, 103 of course, is for ISPs to upgrade their router hardware before DFRT 104 growth outstrips the size of the FIB. This may be too expensive for 105 many ISPs. They would prefer to extend the lifetime of routers whose 106 FIBs can no longer hold the full DFRT. 108 A common approach taken by lower-tier ISPs is to default route to 109 their transit providers. Routes to customers and peer ISPs are 110 maintained, but everything else defaults to the provider. This 111 approach has several disadvantages. First, packets to Internet 112 destinations may take longer-than-necessary Autonomous System (AS) 113 paths. This problem can be mitigated through careful configuration 114 of partial defaults, but this can require substantial configuration 115 overhead. A second problem with defaulting to providers is that the 116 ISP is no longer able to provide the full DFRT to its customers. 117 Finally, provider defaults prevents the ISP from being able to detect 118 martian packets. As a result, the ISP transmits packets that could 119 otherwise have been dropped over its expensive provider links. 121 An alternative is for the ISP to maintain full routes in its core 122 routers, but to filter routes from edge routers that do not require a 123 full DFRT. These edge routers can then default route to the core 124 routers. This is often possible with edge routers that interface to 125 customer networks. The problem with this approach is that it cannot 126 be used for all edge routers. For instance, it cannot be used for 127 routers that connect to transits. It of course also does not help in 128 cases where core routers themselves have inadequate FIB capacity. 130 FIB Suppression is an approach to shrinking FIB size that requires no 131 changes to BGP, no changes to packet forwarding mechanisms in 132 routers, and relatively minor changes to control mechanisms in 133 routers and configuration of those mechanisms. The core idea behind 134 FIB suppression is to run BGP as normal, and in particular to not 135 shrink the RIB, but rather to not load certain RIB entries into the 136 FIB. This approach minimizes changes to routers, and in particular 137 is simpler than more general routing architectures that try to shrink 138 both RIB and FIB. With FIB suppression, there are no changes to BGP 139 per se. The BGP decision process does not change, the selected AS- 140 PATH does not change, and except on rare occasion the exit router 141 does not change. ISPs can deploy FIB suppression autonomously and 142 with no coordination with neighboring ASes. 144 This document describes an approach to FIB suppression called 145 "Virtual Aggregation" (VA). VA operates by organizing the IP (v4 or 146 v6) address space into Virtual Prefixes (VP), and using tunnels to 147 aggregate the (regular) sub-prefixes within each VP. The decrease in 148 FIB size can be dramatic, easily 5x or 10x with only a slight path 149 length and router load increase [nsdi09]. 151 1.1. Scope of this Document 153 The scope of this document is limited to intra-domain VA operation. 154 Individual ASs autonomously operate VA internally without any 155 coordination with neighboring ASs. 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. 160 This document is limited to the following tunnel types: MPLS Label 161 Switched Paths (LSP), and of MPLS inner labels tunneled over either 162 LSPs or IP headers. 164 VA may operate with a mix of upgraded routers and legacy routers. 165 There are no topological restrictions placed on the mix of routers. 166 In order to avoid loops between upgraded and legacy routers, packets 167 are always tunneled by the VA routers to the BGP NEXT_HOPs of the 168 matched BGP routes. If a given local ASBR (Autonomous System Border 169 Router) is a legacy router, it must be able to terminate tunnels. 171 1.2. Requirements notation 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" when 175 capitalized in this document are to be interpreted as described in 176 [RFC2119]. 178 1.3. Terminology 180 Aggregation Point Router (APR): An Aggregation Point Router (APR) is 181 a router that aggregates a Virtual Prefix (VP) by installing 182 routes (into the FIB) for all of the sub-prefixes within the VP. 183 APRs advertise the VP to other routers with BGP. For each sub- 184 prefix within the VP, APRs have a tunnel from themselves to the 185 remote ASBR (Autonomous System Border Router) where packets for 186 that prefix should be delivered. 187 Install and Suppress: The terms "install" and "suppress" are used to 188 describe whether a RIB entry has been loaded or not loaded into 189 the FIB. In particular, "install a route" means "install a route 190 into the FIB", and "suppress a route" means "do not install a 191 route into the FIB". 193 Legacy Router: A router that does not run VA, and has no knowledge 194 of VA. Legacy routers, however, must be able to terminate tunnels 195 when they are local ASBRs. 196 Non-APR Router: In discussing VPs, it is often necessary to 197 distinguish between routers that are APRs for that VP, and routers 198 that are not APRs for that VP (but of course may be APRs for other 199 VPs not under discussion). In these cases, the term "APR" is 200 taken to mean "a VA router that is an APR for the given VP", and 201 the term "non-APR" is taken to mean "a VA router that is not an 202 APR for the given VP". The term non-APR router is not used to 203 refer to legacy routers. 204 Popular Prefix: A Popular Prefix is a sub-prefix that is installed 205 in a router in addition to the sub-prefixes it holds by virtue of 206 being a Aggregation Point Router. The Popular Prefix allows 207 packets to follow the shortest path. Note that different routers 208 do not need to have the same set of Popular Prefixes. 209 Routing Information Base (RIB): The term RIB is used rather sloppily 210 in this document to refer either to the loc-RIB (as used in 211 [RFC4271]), or to the combined Adj-RIBs-In, the Loc-RIB, and the 212 Adj-RIBs-Out. 213 Sub-Prefix: A regular (physically aggregatable) prefix. These are 214 equivalent to the prefixes that would normally comprise the DFRT 215 in the absence of VA. A VA router will contain a sub-prefix entry 216 either because the sub-prefix falls within a Virtual Prefix for 217 which the router is an APR, or because the sub-prefix is installed 218 as a Popular Prefix. Legacy routers hold the same sub-prefixes 219 that they hold today. 220 Tunnel: This document specifies the use of MPLS Label Switched Paths 221 (LSP), and of MPLS inner labels tunneled over either LSPs or IP 222 headers. While in principle other types of tunnels may be used, 223 they are not specified here. This document uses the term tunnel 224 to refer to the above MPLS encapsulations. 225 VA router: A router that operates Virtual Aggregation according to 226 this document. 227 Virtual Prefix (VP): A Virtual Prefix (VP) is a prefix used to 228 aggregate its contained regular prefixes (sub-prefixes). The set 229 of sub-prefixes in a VP are not physically aggregatable, and so 230 they are aggregated at APRs through the use of tunnels. 231 VP-List: A list of defined VPs. All routers must agree on the 232 contents of this list. 234 2. Overview of Virtual Aggregation (VA) 236 For descriptive simplicity, this section starts by describing VA 237 assuming that there are no legacy routers in the domain. Section 2.1 238 overviews the additional functions required by VA routers to 239 accommodate legacy routers. 241 A key concept behind VA is to operate BGP as normal, and in 242 particular to populate the RIB with the full DFRT, but to suppress 243 many or most prefixes from being loaded into the FIB. By populating 244 the RIB as normal, we avoid any changes to BGP, and changes to router 245 operation are relatively minor. The basic idea behind VA is as 246 follows: The address space is partitioned into large prefixes --- 247 larger than any aggregatable prefix in use today. These prefixes are 248 called Virtual Prefixes (VP). Different VPs do not need to be the 249 same size. They may be a mix of /6, /7, /8 (for IPv4), and so on. 250 Indeed, an ISP can define a single /0 VP, and use it for a core/edge 251 type of configuration. That is, the core routers would maintain full 252 FIBs, and edge routers could maintain default routes to the core 253 routers, and suppress as much of the FIB as they wish. Each ISP can 254 independently select the size of its VPs. 256 VPs are not themselves topologically aggregatable. VA makes the VPs 257 aggregatable through the use of tunnels, as follows. Associated with 258 each VP are one or more "Aggregation Point Routers" (APR). An APR 259 (for a given VP) is a router that installs routes for all sub- 260 prefixes (i.e. real physically aggregatable prefixes) within the VP. 261 By "install routes" here, we mean: 263 1. The route for each of the sub-prefixes is loaded into the FIB, 264 and 265 2. there is a tunnel from the APR to the BGP NEXT_HOP for the route. 267 The APR originates a BGP route to the VP. This route is distributed 268 within the domain, but not outside the domain. With this structure 269 in place, a packet transiting the ISP goes from the ingress router to 270 the APR (usually via a tunnel), and then from the APR to the BGP 271 NEXT_HOP router via a tunnel. VA can operate with MPLS LSPs, or with 272 MPLS inner labels over LSPs or IP headers. Section 4 specifies the 273 usage of MPLS tunnels. Other tunnel types (i.e., GRE) may be used, 274 but are not specified in this document. 276 The BGP NEXT_HOP can be either the local ASBR or the remote ASBR. In 277 the former case, an inner label is used to tunnel packets 278 (Section 4.1). In either case, all tunnel headers are stripped by 279 the local ASBR before the packet is delivered to the remote ASBR. In 280 other words, the remote ASBR sees a normal IP packet, and is 281 completely unaware of the existence of VA in the neighboring ISP. 283 Note that the AS-PATH is not effected at all by VA. This means among 284 other things that AS-level policies are not effected by VA. The 285 packet may not, however, follow the shortest path within the ISP 286 (where shortest path is defined here as the path that would have been 287 taken if VA were not operating), because the APR may not be on the 288 shortest path between the ingress and egress routers. When this 289 happens, the packet experiences additional latency and creates extra 290 load (by virtue of taking more hops than it otherwise would have). 291 Note also that, with VA, a packet may occasionally take a different 292 exit point than it otherwise would have. This can occur for instance 293 when the exit point nearest to the selected APR is different than the 294 exit point nearest to the router initiating the tunnel to the APR. 296 VA can avoid traversing the APR for selected routes by installing 297 these routes in non-APR routers. In other words, even if an ingress 298 router is not an APR for a given sub-prefix, it MAY install that sub- 299 prefix into its FIB. Packets in this case are tunneled directly from 300 the ingress to the BGP NEXT_HOP. These extra routes are called 301 "Popular Prefixes", and are typically installed for policy reasons 302 (e.g. customer routes are always installed), or for sub-prefixes that 303 carry a high volume of traffic (Section 3.5.1). Different routers 304 may have different Popular Prefixes. As such, an ISP may assign 305 Popular Prefixes per router, per POP, or uniformly across the ISP. A 306 given router may have zero Popular Prefixes, or the majority of its 307 FIB may consist of Popular Prefixes. The effectiveness of Popular 308 Prefixes to reduce traffic load relies on the fact that traffic 309 volumes follow something like a power-law distribution: i.e. that 90% 310 of traffic is destined to 10% of the destinations. Internet traffic 311 measurement studies over the years have consistently shown that 312 traffic patterns follow this distribution [nsdi09], though there is 313 no guarantee that they always will. 315 Note that for routing to work properly, every packet must sooner or 316 later reach a router that has installed a sub-prefix route that 317 matches the packet. This would obviously be the case for a given 318 sub-prefix if every router has installed a route for that sub-prefix. 319 If this is not the case, then there MUST be at least one Aggregation 320 Point Router (APR) for the sub-prefix's Virtual Prefix (VP). 321 Ideally, every POP contains at least two APRs for every Virtual 322 Prefix. By having APRs in every POP, the latency imposed by routing 323 to the APR is minimal (the extra hop is within the POP). By having 324 more than one APR, there is a redundant APR should one fail. In 325 practice it is often not possible to have an APR for every VP in 326 every POP. This is because some POPs may have only one or a few 327 routers, and therefore there may not have enough cumulative FIB space 328 in the POP to hold every sub-prefix. Note that any router ("edge", 329 "core", etc.) MAY be an APR. 331 It is important that both the contents of BGP RIBs, as well as the 332 contents of the Routing Table (as defined in Section 3.2 of 333 [RFC4271]) not be modified by VA (other than the introduction of 334 routes to VPs). This is because PIM-SM [RFC4601] relies on the 335 contents of the Routing Table to build its own trees and forwarding 336 table. Therefore, FIB suppression MUST take place between the 337 Routing Table and the actual FIB(s). 339 2.1. Mix of Legacy and VA Routers 341 It is important that an ISP be able to operate with a mix of "VA 342 routers" and "legacy routers". This allows ISPs to deploy VA in an 343 incremental fashion and to continue to use routers that for whatever 344 reason cannot be upgraded. This document allows such a mix, and 345 indeed places no topological restrictions on that mix. It does, 346 however, require that legacy routers are able to forward tunneled 347 packets, are able to serve as tunnel endpoints, and are able to 348 participate in distribution of tunnel information required to 349 establish themselves as tunnel endpoints. Depending on the tunnel 350 type, legacy routers MAY also be able to initiate tunneled packets, 351 though this is an OPTIONAL requirement. Legacy routers MUST use 352 their own address as the BGP NEXT_HOP. 354 2.2. Summary of Tunnels and Paths 356 To summarize, the following tunnels are created: 358 1. From all VA routers to all BGP NEXT_HOP addresses (where the BGP 359 NEXT_HOP address is either an APR, a local ASBR, or the remote 360 ASBR neighbor of a VA router). 361 2. Optionally, from all legacy routers to all BGP NEXT_HOP 362 addresses. 363 There are a number of possible paths that packets may take through an 364 ISP, summarized in the following diagram. Here, "VA" is a VA router, 365 "LR" is a legacy router, the symbol "==>" represents a tunneled 366 packet (through zero or more routers), "-->" represents an untunneled 367 packet, and "(pop)" represents stripping the tunnel header. The 368 symbol "::>" represents the portion of the path where although the 369 tunnel is targeted to the receiving node, the outer header has been 370 stripped. 372 Egress 373 Router 374 Ingress Some APR (Local Remote 375 Router Router Router ASBR) ASBR 376 ------- ------ ------ ------ -------- 377 1. VA===================>VA=========>VA(pop)::::>Peer ASBR 379 2. VA===================>VA=========>LR--------->Peer ASBR 381 3. VA===============================>VA(pop)::::>Peer ASBR 383 4. VA===============================>LR--------->Peer ASBR 385 (The following two exist in the case where legacy routers 386 can initiate tunneled packets.) 388 5. LR===============================>VA(pop)::::>Peer ASBR 390 6. LR===============================>LR--------->Peer ASBR 392 (The following two exist in the case where legacy routers 393 cannot initiate tunneled packets.) 395 7. LR------->VA (remaining paths as in 1 to 4 above) 397 8. LR------->LR--------------------->LR--------->Peer ASBR 399 The first and second paths represent the case where the ingress 400 router does not have a Popular Prefix for the destination, and MUST 401 tunnel the packet to an APR. The third and fourth paths represent 402 the case where the ingress router does have a Popular Prefix for the 403 destination, and so tunnels the packet directly to the egress. The 404 fifth and sixth paths are similar to the third and fourth paths 405 respectively, but where the ingress is a legacy router that can 406 initiate tunneled packets, and effectively has the Popular Prefix by 407 virtue of holding the entire DFRT. (Note that some ISPs have only 408 partial RIBs in their customer-facing edge routers, and default route 409 to a router that holds the full DFRT. This case is not shown here, 410 but works perfectly well.) Finally, paths 7 and 8 represent the case 411 where legacy routers cannot initiate a tunneled packet. 413 VA prevents the routing loops that might otherwise occur when VA 414 routers and legacy routers are mixed. In particular, VA avoids the 415 case where a legacy router is forwarding packets towards the BGP 416 NEXT_HOP, while a VA router is forwarding packets towards the APR, 417 with each router thinking that the other is on the shortest path to 418 their respective targets. 420 In the first four types of path, the loop is avoided because tunnels 421 are used all the way to the egress. As a result, there is never an 422 opportunity for a legacy router to try to route based on the 423 destination address unless the legacy router is the egress, in which 424 case it forwards the packet to the remote ASBR. 426 In the 5th and 6th cases, the ingress is a legacy router, but this 427 router can initiate tunnels and has the full FIB, and so simply 428 tunnels the packet to the egress router. 430 In the 7th and 8th cases, the legacy ingress cannot initiate tunnels, 431 and so forwards the packet hop-by-hop towards the BGP NEXT_HOP. The 432 packet will work its way towards the egress router, and will either 433 progress through a series of legacy routers (in which case the IGP 434 prevents loops), or it will eventually reach a VA router, after which 435 it will take tunnels as in the 1st and 2nd cases. 437 3. Specification of VA 439 This section describes in detail how to operate VA. 441 3.1. Legacy Routers 443 VA can operate with a mix of VA and legacy routers. To prevent the 444 types of loops described in Section 2.2, however, legacy routers MUST 445 satisfy the following requirements: 447 1. When forwarding externally-received routes over iBGP, the BGP 448 NEXT_HOP attribute MUST be set to the legacy router itself. 449 2. Legacy routers MUST be able to detunnel packets addressed to 450 themselves at the BGP NEXT_HOP address. They MUST also be able 451 to convey the tunnel information needed by other routers to 452 initiate tunneled packets to them. If a legacy router cannot 453 detunnel and convey tunnel parameters, then the AS cannot use VA. 454 3. Legacy routers MUST be able to forward all tunneled packets. 455 4. Every legacy router MUST hold its complete FIB. Note, however, 456 that this FIB does not necessarily need to contain the full DFRT. 457 This might be the case, for instance, if the router is an edge 458 router that defaults to a core router. 460 As long as legacy routers participating in tunneling as described 461 above there are no topological restrictions on the legacy routers. 462 They may be freely mixed with VA routers without the possibility of 463 forming sustained loops (Section 2.2). 465 3.2. Advertising and Handling Virtual Prefixes (VP) 467 3.2.1. Distinguishing VPs from Sub-prefixes 469 VA routers MUST be able to distinguish VPs from sub-prefixes. This 470 is primarily in order to know which routes to install. In 471 particular, non-APR routers SHOULD know which prefixes are VPs before 472 they receive routes for those VPs, for instance when they first boot 473 up. This is in order to avoid the situation where they unnecessarily 474 start filling their FIBs with routes that they ultimately don't need 475 to install (Section 3.5). This leads to the following requirement: 477 It MUST be possible to configure the complete list of VPs into all VA 478 routers. This list is known as the VP-List. 480 3.2.2. Limitations on Virtual Prefixes 482 From the point of view of best-match routing semantics, VPs are 483 treated identically to any other prefix. In other words, if the 484 longest matching prefix is a VP, then the packet is routed towards 485 the VP. If a packet matching a VP reaches an APR for that VP, and 486 the APR does not have a better matching route, then the packet is 487 discarded by the APR (just as a router that originates any prefix 488 will discard a packet that does not have a better match). 490 The overall semantics of VPs, however, are slightly different from 491 those of real prefixes. Without VA, when a router originates a route 492 for a (real) prefix, the expectation is that the addresses within the 493 prefix are within the originating AS (or a customer of the AS). For 494 VPs, this is not the case. APRs originate VPs whose sub-prefixes 495 exist in different ASes. Because of this, VPs MUST not be advertised 496 across AS boundaries. This is done with NO_EXPORT Communities 497 Attribute (Section 3.2.3). 499 It is up to individual domains to define their own VPs. VPs MUST be 500 "larger" (span a larger address space) than any real sub-prefix. If 501 a VP is smaller than a real prefix, then packets that match the real 502 prefix will nevertheless be routed to an APR owning the VP, at which 503 point the packet will be dropped if it does not match a sub-prefix 504 within the VP (Section 6). 506 (Note that, in principle there are cases where a VP could be smaller 507 than a real prefix. This is where the egress router to the real 508 prefix is a VA router. In this case, the APR could theoretically 509 tunnel the packet to the appropriate remote ASBR, which would then 510 forward the packet correctly. On the other hand, if the egress 511 router is a legacy router, then the APR could not tunnel matching 512 packets to the egress. This is because the egress would view the VP 513 as a better match, and would loop the packet back to the APR. For 514 this reason we require that VPs be larger than any real prefixes, and 515 that APRs never install prefixes larger than a VP in their FIBs.) 517 It is valid for a VP to be a subset of another VP. For example, 20/7 518 and 20/8 can both be VPs. In fact, this capability is necessary for 519 "splitting" a VP without temporarily increasing the FIB size in any 520 router. (Section 3.2.5). 522 3.2.3. Aggregation Point Routers (APR) 524 For each VP for which a router is an APR, the router does the 525 following: 527 1. The APR MUST originate a BGP route to the VP. In this route, the 528 NLRI are all of the VPs for which the router is an APR. This is 529 true even for VPs that are a subset of another VP. The ORIGIN is 530 set to INCOMPLETE (value 2), the AS number of the APR's AS is 531 used in the AS_PATH, and the BGP NEXT_HOP is set to the address 532 of the APR. The ATOMIC_AGGREGATE and AGGREGATOR attributes are 533 not included. 534 2. The APR MUST attach a NO_EXPORT Communities Attribute [RFC1997] 535 to the route. 536 3. The APR MUST be able to detunnel packets addressed to itself at 537 its BGP NEXT_HOP address. It MUST also be able to convey the 538 tunnel information needed by other routers to initiate tunneled 539 packets to them. 540 4. If a packet is received at the APR whose best match route is the 541 VP (i.e. it matches the VP but not any sub-prefixes within the 542 VP), then the packet MUST be discarded (see Section 3.2.2). This 543 can be accomplished by never installing a prefix larger than the 544 VP into the FIB, or by installing the VP as a route to \dev\null. 546 3.2.3.1. Selecting APRs 548 An ISP is free to select APRs however it chooses. The details of 549 this are outside the scope of this document. Nevertheless, a few 550 comments are made here. In general, APRs should be selected such 551 that the distance to the nearest APR for any VP is small---ideally 552 within the same POP. Depending on the number of routers in a POP, 553 and the sizes of the FIBs in the routers relative to the DFRT size, 554 it may not be possible for all VPs to be represented in a given POP. 555 In addition, there should be multiple APRs for each VP, again ideally 556 in each POP, so that the failure of one does not unduly disrupt 557 traffic. 559 3.2.4. Non-APR Routers 561 A non-APR router MUST install at least the following routes: 563 1. Routes to VPs (identifiable using the VP-List). 564 2. Routes to all sub-prefixes that are not covered by any VP in the 565 VP-List. 567 If the non-APR has a tunnel to the BGP NEXT_HOP of any such route, it 568 MUST use the tunnel to forward packets to the BGP NEXT_HOP. 570 When an APR fails, routers must select another APR to send packets to 571 (if there is one). This happens, however, through normal internal 572 BGP convergence mechanisms. 574 3.2.5. Adding and deleting VPs 576 An ISP may from time to time wish to reconfigure its VP-List. There 577 are a number of reasons for this. For instance, early in its 578 deployment an ISP may configure one or a small number of VPs in order 579 to test VA. As the ISP gets more confident with VA, it may increase 580 the number of VPs. Or, an ISP may start with a small number of large 581 VPs (i.e. /4's or even one /0), and over time move to more smaller 582 VPs in order to save even more FIB. In this case, the ISP will need 583 to "split" a VP. Finally, since the address space is not uniformly 584 populated with prefixes, the ISP may want to change the size of VPs 585 in order to balance FIB size across routers. This can involve both 586 splitting and merging VPs. Of course, an ISP must be able to modify 587 its VP-List without 1) interrupting service to any destinations, or 588 2) temporarily increasing the size of any FIB (i.e. where the FIB 589 size during the change is no bigger than its largest size either 590 before or after the change). 592 The first step for adding a VP is to configure the APRs for the VP. 593 This causes the APRs to originate routes for the VP. Non-APR routers 594 will install this route according to the rules in Section 3.2.4 even 595 though they do not yet recognize that the prefix is a VP. 596 Subsequently the VP is added to the VP-List of non-APR routers. The 597 Non-APR routers can then start suppressing the sub-prefixes with no 598 loss of service. 600 To delete a VP, the process is reversed. First, the VP is removed 601 from the VP-Lists of non-APRs. This causes the non-APRs to install 602 the sub-prefixes. After all sub-prefixes have been installed, the VP 603 may be removed from the APRs. 605 In many cases, it is desirable to split a VP. For instance, consider 606 the case where two routers, Ra and Rb, are APRs for the same prefix. 608 It would be possible to shrink the FIB in both routers by splitting 609 the VP into two VPs (i.e. split one /6 into two /7's), and assigning 610 each router to one of the VPs. While this could in theory be done by 611 first deleting the larger VP, and then adding the smaller VPs, doing 612 so would temporarily increase the FIB size in non-APRs, which may not 613 have adequate space for such an increase. For this reason, we allow 614 overlapping VPs. 616 To split a VP, first the two smaller VPs are added to the VP-Lists of 617 all non-APR routers (in addition to the larger superset VP). Next, 618 the smaller VPs are added to the selected APRs (which may or may not 619 be APRs for the larger VP). Because the smaller VPs are a better 620 match than the larger VP, this will cause the non-APR routers to 621 forward packets to the APRs for the smaller VPs. Next, the larger VP 622 can be removed from the VP-Lists of all non-APR routers. Finally, 623 the larger VP can be removed from its APRs. 625 To merge two VPs, the new larger VP is configured in all non-APRs. 626 This has no effect on FIB size or APR selection, since the smaller 627 VPs are better matches. Next the larger VP is configured in its 628 selected APRs. Next the smaller VPs are deleted from all non-APRs. 629 Finally, the smaller VPs are deleted from their corresponding APRs. 631 3.3. Border VA Routers 633 A VA router that is an ASBR MUST do the following: 635 1. When forwarding externally-received routes over iBGP, if a tunnel 636 with an inner label is used, the ASBR MUST set the BGP NEXT_HOP 637 attribute to itself. Otherwise, the BGP NEXT_HOP attribute is 638 left unchanged. 639 2. They MUST establish tunnels as described in Section 4. 640 3. The ASBR MUST detunnel the packet before forwarding the packet to 641 the remote ASBR. 642 4. The ASBR MUST be able to forward the packet without a FIB lookup. 643 In other words, the tunnel information itself contains all the 644 information needed by the border router to know which remote ASBR 645 should receive the packet. 647 3.4. Advertising and Handling Sub-Prefixes 649 Sub-prefixes are advertised and handled by BGP as normal. VA does 650 not effect this behavior. The only difference in the handling of 651 sub-prefixes is that they might not be installed in the FIB, as 652 described in Section 3.5. 654 In those cases where the route is installed, packets forwarded to 655 prefixes external to the AS MUST be transmitted via the tunnel 656 established as described in Section 3.3. 658 3.5. Suppressing FIB Sub-prefix Routes 660 Any route not for a known VP (i.e. not in the VP-List) is taken to be 661 a sub-prefix. The following rules are used to determine if a sub- 662 prefix route can be suppressed. 664 1. A VA router MUST NOT FIB-install a sub-prefix route for which 665 there is no tunnel to the BGP NEXT_HOP address. This is to 666 prevent a loop whereby the APR forwards the packet hop-by-hop 667 towards the next hop, but a router on the path that has FIB- 668 suppressed the sub-prefix forwards it back to the APR. 669 2. If the router is an APR, a route for every sub-prefix within the 670 VP MUST be FIB-installed (subject to the above limitation that 671 there be a tunnel). 672 3. If a non-APR router has a sub-prefix route that does not fall 673 within any VP (as determined by the VP-List), then the route MUST 674 be installed. This may occur because the ISP hasn't defined a VP 675 covering that prefix, for instance during an incremental 676 deployment build-up. 677 4. If an ASBR is using strict uRPF to do ingress filtering, then it 678 MUST install routes for which the remote ASBR is the BGP NEXT_HOP 679 [RFC2827]. Note that only an APR may do loose uRPF filtering, 680 and then only for routes to sub-prefixes within its VPs. 681 5. All other sub-prefix routes MAY be suppressed. Such "optional" 682 sub-prefixes that are nevertheless installed are referred to as 683 Popular Prefixes. Note, however, that whether or not to install 684 a given sub-prefix SHOULD NOT be based on whether or not there is 685 an active route to a VP in the VP-List. This avoids the 686 situation whereby, during BGP initialization, the router receives 687 some sub-prefix routes before receiving the corresponding VP 688 route, with the result that it installs routes in its FIB that it 689 will only remove a short time later, possibly even overflowing 690 its FIB. 692 3.5.1. Selecting Popular Prefixes 694 Individual routers MAY independently choose which sub-prefixes are 695 Popular Prefixes. There is no need for different routers to install 696 the same sub-prefixes. There is therefore significant leeway as to 697 how routers select Popular Prefixes. As a general rule, routers 698 should fill the FIB as much as possible, because the cost of doing so 699 is relatively small, and more FIB entries leads to fewer packets 700 taking a longer path. Broadly speaking, an ISP may choose to fill 701 the FIB by making routers APRs for as many VPs as possible, or by 702 assigning relatively few APRs and rather filling the FIB with Popular 703 Prefixes. Several basic approaches to selecting Popular Prefixes are 704 outlined here. Router vendors are free to implement whatever 705 approaches they want. 707 1. Policy-based: The simplest approach for network administrators is 708 to have broad policies that routers use to determine which sub- 709 prefixes are designated as popular. An obvious policy would be a 710 "customer routes" policy, whereby all customer routes are 711 installed (as identified for instance by appropriate community 712 attribute tags). Another policy would be for a router to install 713 prefixes originated by specific ASes. For instance, two ISPs 714 could mutually agree to install each other's originated prefixes. 715 A third policy might be to install prefixes with the shortest AS- 716 PATH. 717 2. Static list: Another approach would be to configure static lists 718 of specific prefixes to install. For instance, prefixes 719 associated with an SLA might be configured. Or, a list of 720 prefixes for the most popular websites might be installed. 721 3. High-volume prefixes: By installing high-volume prefixes as 722 Popular Prefixes, the latency and load associated with the longer 723 path required by VA is minimized. One approach would be for an 724 ISP to measure its traffic volume over time (days or a few 725 weeks), and statically configure high-volume prefixes as Popular 726 Prefixes. There is strong evidence that prefixes that are high- 727 volume tend to remain high-volume over multi-day or multi-week 728 timeframes (though not necessarily at short timeframes like 729 minutes or seconds). High-volume prefixes MAY also be installed 730 automatically. For this, a router measures its own traffic 731 volumes, and installs and removes Popular Prefixes in response to 732 changes in traffic load. The downside of this approach is that 733 it complicates debugging network problems. If packets are being 734 dropped somewhere in the network, it is more difficult to find 735 out where if the selected path can change dynamically. 737 3.6. New Configuration 739 VA places new configuration requirements on ISP administrators. 740 Namely, the administrator does the following. 742 1. Select VPs, and configure the VP-List into all VA routers. As a 743 general rule, having a larger number of relatively small prefixes 744 gives administrators the most flexibility in terms of filling 745 available FIB with sub-prefixes, and in terms of balancing load 746 across routers. Once an administrator has selected a VP-List, it 747 is just as easy to configure routers with a large list as a small 748 list. A good list might be one where the number of VPs is 749 relatively large, say 100 or so (noting again that each VP must 750 be smaller than a real prefix), and the number of sub-prefixes 751 within each VP is roughly the same. 753 2. Select and configure APRs. There are three primary 754 considerations here. First, there needs to be enough APRs to 755 failover to should one or more APRs crash. Second, APR 756 assignment should not result in router overload. Third, 757 excessively long paths should be avoided. Ideally there should 758 be two APRs for each VP within each PoP, but this may not be 759 possible for small PoPs. Failing this, there should be at least 760 two APRs in each geographical region, so as to minimize path 761 length increase. Routers should have the appropriate counters to 762 allow administrators to know the volume of APR traffic each 763 router is handling so as to adjust load by adding or removing APR 764 assignments. 765 3. Select and configure Popular Prefixes or Popular Prefix policies. 766 There are two general goals here. The first is to minimize load 767 overall by minimizing the number of packets that take longer 768 paths. The second is to insure that specific selected prefixes 769 don't have overly long paths. These goals have to be weighed 770 against the administrative overhead of configuring potentially 771 thousands of Popular Prefixes. As one example a small ISP may 772 wish to keep it simple by doing nothing more than indicating that 773 customer routes should be installed. In this case, the 774 administrator could otherwise assign as many APRs as possible 775 while leaving enough FIB space for customer routes. As another 776 example, a large ISP could build a management system that takes 777 into consideration the traffic matrix, customer SLAs, robustness 778 requirements, FIB sizes, topology, and router capacity, and 779 periodically automatically computes APR and Popular Prefix 780 assignments. 782 3.7. Interaction with Traffic Engineering 784 In VA, some traffic traverses an APR as an intermediate "hop", and 785 some does not. For that traffic that does not, there is no 786 difference between how that traffic is handled and how it is handled 787 in a non-VA network with edge-to-edge tunnels. As a result, there 788 should be no difference in how traffic engineering operates on that 789 traffic. 791 For traffic that does traverse APR "hop", the following holds: Any 792 traffic engineering decisions that affect the BGP NEXT_HOP must be 793 made at the APR. Traffic engineering decisions that effects the 794 router path through the AS may be handled in one of two ways. First, 795 the path decision may simply be made twice independently, once for 796 the ingress-to-APR tunnel, and once for the APR-to-egress tunnel. 797 This approach requires no changes to the traffic engineering 798 mechanisms per se, but it may not make optimal path selection 799 decisions. Second, the traffic engineering decision may take into 800 account both tunnels, even to the point of choosing among multiple 801 transit APRs. This approach may be more optimal, but is more complex 802 and requires changes to existing mechanisms. 804 Overall, if the majority of traffic does not involve an APR "hop", 805 for instance through the use of popular prefixes, then VA in any 806 event has a minimal impact on traffic engineering, and so the impact 807 of VA may potentially be ignored. 809 4. Usage of MPLS Tunnels 811 VA utilizes a straight-forward application of MPLS. The tunnels are 812 MPLS Label Switched Paths (LSP), and are signaled using either the 813 Label Distribution Protocol (LDP) [RFC5036] or RSVP-TE [RFC3209]. 814 Both VA and legacy routers MUST participate in this signaling. 816 APRs and ASBRs initiate tunnels. In both cases, Downstream 817 Unsolicited tunnels are initiated to all IGP neighbors with the full 818 BGP NEXT_HOP address as the Forwarding Equivalence Class (FEC). In 819 the case of APRs, the BGP NEXT_HOP is the APR's own address. In the 820 case of legacy ASBRs, the BGP NEXT_HOP is the ASBR's own address. In 821 the case of VA ASBRs, the BGP NEXT_HOP is that of the remote ASBR. 823 Existing Penultimate Hop Popping (PHP) mechanisms in the data plane 824 can be used for forwarding packets to remote ASBRs. 826 4.1. Usage of Inner Label 828 Besides using a separate LSP to identify the remote ASBR as described 829 above, it is also possible to use an inner label to identify the 830 remote ASBR. Either an outer label or an IP tunnel identifies the 831 local ASBR. 833 When a local ASBR advertises a route into iBGP, it sets the NEXT_HOP 834 to itself, and assigns a label to the route. This label is used as 835 the inner label, and identifies the remote ASBR from which the route 836 was received [RFC3107]. 838 The presence of the inner label in the iBGP update acts as the signal 839 to the receiving router that an inner label MUST be used in packets 840 tunneled to the NEXT_HOP address. If there is an LSP established 841 targeted to the NEXT_HOP address, then it is used to tunnel the 842 packet to the NEXT_HOP address. Otherwise, an IP header address to 843 the NEXT_HOP address is used. 845 5. IANA Considerations 847 There are no IANA considerations. 849 6. Security Considerations 851 We consider the security implications of VA under two scenarios, one 852 where VA is assumed to be configured and operated correctly, and one 853 where it is mis-configured. A cornerstone of VA operation is that 854 the basic behavior of BGP doesn't change, especially inter-domain. 855 Among other things, this makes it easier to reason about security. 857 6.1. Properly Configured VA 859 If VA is configured and operated properly, then the external behavior 860 of an AS does not change. The same upstream ASes are selected, and 861 the same prefixes and AS-PATHs are advertised. Therefore, a properly 862 configured VA domain has no security impact on other domains. 864 If another ISP starts advertising a prefix that is larger than a 865 given VP, this prefix will be ignored by APRs that have a VP that 866 falls within the larger prefix (Section 3.2.3). As a result, packets 867 that might otherwise have been routed to the new larger prefix will 868 be dropped at the APRs. Note that the trend in the Internet is 869 towards large prefixes being broken up into smaller ones, not the 870 reverse. Therefore, such a larger prefix is likely to be invalid. 871 If it is determined without a doubt that the larger prefix is valid, 872 then the ISP will have to reconfigure its VPs. 874 VA does not change an ISP's ability to do ingress filtering using 875 strict uRPF (Section 3.5). 877 Regarding DoS attacks, there are two issues that need to be 878 considered. First, does VA result in new types of DoS attacks? 879 Second, does VA make it more difficult to deploy DoS defense systems. 880 Regarding the first issue, one possibility is that an attacker 881 targets a given router by flooding the network with traffic to 882 prefixes that are not popular, and for which that router is an APR. 883 This would cause a disproportionate amount of traffic to be forwarded 884 to the APR(s). While it is up to individual ISPs to decide if this 885 attack is a concern, it does not strike the authors that this attack 886 is likely to significantly worsen the DoS problem. 888 Many DoS defense systems use dynamically established Routing Table 889 entries to divert victims' traffic into LSPs that carry the traffic 890 to scrubbers. This mechanism works with VA---it simply over-rides 891 whatever route is in place. This mechanism works equally well with 892 APRs and non-APRs. 894 6.2. Mis-configured VA 896 VA introduces the possibility that a VP is advertised outside of an 897 AS. This in fact should be a low probability event since routers 898 filter these, but it is considered here none-the-less. 900 If an AS leaks a large VP (i.e. larger than any real prefixes), then 901 the impact is minimal. Smaller prefixes will be preferred because of 902 best-match semantics, and so the only impact is that packets that 903 otherwise have no matching routes will be sent to the misbehaving AS 904 and dropped there. If an AS leaks a small VP (i.e. smaller than a 905 real prefix), then packets to that AS will be hijacked by the 906 misbehaving AS and dropped. (This can happen with or without VA, and 907 so doesn't represent a new security problem per se.) 909 Although VPs MUST be larger than real prefixes, there is 910 intentionally no mechanism designed to automatically insure that this 911 is the case. Such a mechanisms would be dangerous. For instance, if 912 an ISP somewhere advertised a very large prefix (a /4, say), then 913 this would cause APRs to throw out all VPs that are smaller than 914 this. For this reason, VPs must be set through configuration only. 916 7. Acknowledgements 918 The authors would like to acknowledge the efforts of Xinyang Zhang 919 and Jia Wang, who worked on CRIO (Core Router Integrated Overlay), an 920 early inter-domain variant of FIB suppression, and the efforts of 921 Hitesh Ballani and Tuan Cao, who worked on the configuration-only 922 variant of VA that works with legacy routers. We would also like to 923 thank Scott Brim, Daniel Ginsburg, and Rajiv Asati for their helpful 924 comments. In particular, Daniel's comments significantly simplified 925 the spec (eliminating the need for a new Extended Communities 926 Attribute). Finally, we would like to thank Wes George, Med 927 Boucadair, and Bruno Decraene for their reviews and suggestions. 929 8. References 931 8.1. Normative References 933 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 934 Communities Attribute", RFC 1997, August 1996. 936 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 937 Requirement Levels", BCP 14, RFC 2119, March 1997. 939 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 940 Defeating Denial of Service Attacks which employ IP Source 941 Address Spoofing", BCP 38, RFC 2827, May 2000. 943 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 944 BGP-4", RFC 3107, May 2001. 946 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 947 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 948 Tunnels", RFC 3209, December 2001. 950 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 951 Protocol 4 (BGP-4)", RFC 4271, January 2006. 953 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 954 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 955 Protocol Specification (Revised)", RFC 4601, August 2006. 957 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 958 Specification", RFC 5036, October 2007. 960 8.2. Informative References 962 [I-D.ietf-grow-simple-va] 963 Francis, P., Xu, X., Ballani, H., Raszuk, R., and L. 964 Zhang, "Simple Virtual Aggregation (S-VA)", 965 draft-ietf-grow-simple-va-00 (work in progress), 966 March 2010. 968 [I-D.ietf-grow-va-gre] 969 Francis, P., Raszuk, R., and X. Xu, "GRE and IP-in-IP 970 Tunnels for Virtual Aggregation", 971 draft-ietf-grow-va-gre-00 (work in progress), July 2009. 973 [I-D.ietf-grow-va-mpls] 974 Francis, P. and X. Xu, "MPLS Tunnels for Virtual 975 Aggregation", draft-ietf-grow-va-mpls-00 (work in 976 progress), May 2009. 978 [I-D.ietf-grow-va-mpls-innerlabel] 979 Xu, X. and P. Francis, "Proposal to use an inner MPLS 980 label to identify the remote ASBR VA", 981 draft-ietf-grow-va-mpls-innerlabel-00 (work in progress), 982 September 2009. 984 [nsdi09] Ballani, H., Francis, P., Cao, T., and J. Wang, "Making 985 Routers Last Longer with ViAggre", ACM Usenix NSDI 2009 ht 986 tp://www.usenix.org/events/nsdi09/tech/full_papers/ 987 ballani/ballani.pdf, April 2009. 989 Authors' Addresses 991 Paul Francis 992 Max Planck Institute for Software Systems 993 Gottlieb-Daimler-Strasse 994 Kaiserslautern 67633 995 Germany 997 Phone: +49 631 930 39600 998 Email: francis@mpi-sws.org 1000 Xiaohu Xu 1001 Huawei Technologies 1002 No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District 1003 Beijing, Beijing 100085 1004 P.R.China 1006 Phone: +86 10 82836073 1007 Email: xuxh@huawei.com 1009 Hitesh Ballani 1010 Cornell University 1011 4130 Upson Hall 1012 Ithaca, NY 14853 1013 US 1015 Phone: +1 607 279 6780 1016 Email: hitesh@cs.cornell.edu 1018 Dan Jen 1019 UCLA 1020 4805 Boelter Hall 1021 Los Angeles, CA 90095 1022 US 1024 Phone: 1025 Email: jenster@cs.ucla.edu 1026 Robert Raszuk 1027 Cisco Systems, Inc. 1028 170 West Tasman Drive 1029 San Jose, CA 95134 1030 USA 1032 Phone: 1033 Email: raszuk@cisco.com 1035 Lixia Zhang 1036 UCLA 1037 3713 Boelter Hall 1038 Los Angeles, CA 90095 1039 US 1041 Phone: 1042 Email: lixia@cs.ucla.edu