idnits 2.17.1 draft-ietf-grow-simple-va-10.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 (July 5, 2012) is 4306 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4271' is mentioned on line 138, but not defined == Unused Reference: 'RFC5082' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-grow-va' is defined on line 298, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 GROW Working Group R. Raszuk 2 Internet-Draft NTT MCL 3 Intended status: Informational J. Heitz 4 Expires: January 6, 2013 Ericsson 5 A. Lo 6 Arista 7 L. Zhang 8 UCLA 9 X. Xu 10 Huawei 11 July 5, 2012 13 Simple Virtual Aggregation (S-VA) 14 draft-ietf-grow-simple-va-10.txt 16 Abstract 18 All BGP routers in the Default Free Zone (DFZ) are required to carry 19 all the routes in the Default Free Routing Table (DFRT). A technique 20 is described that allows some BGP routers not to install all of those 21 routes into the Forwarding Information Base (FIB). 23 Some routers in an Autonomous System (AS) announce an aggregate (the 24 VA prefix) in addition to the routes they already announce. This 25 enables other routers not to install the routes covered by the VA 26 prefix into the FIB as long as those routes have the same next-hop as 27 the VA prefix. 29 The VA prefixes that are announced within an AS are not announced to 30 any other AS. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 6, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3 68 1.2. Requirements notation . . . . . . . . . . . . . . . . . . . 3 69 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Deployment considerations . . . . . . . . . . . . . . . . . . . 6 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 A technique called Simple Virtual Aggregation (S-VA) is described. 83 It allows some routers not to have to store some routes in the 84 Forwarding Information Base (FIB) while still advertising and 85 receiving the full Default Free Routing Table (DFRT) in BGP. 87 A typical scenario is as follows. Core routers in the ISP maintain 88 the full DFRT in the FIB and RIB. Edge routers maintain the full 89 DFRT in the BGP Loc-RIB, but do not install certain routes in the RIB 90 and FIB. Edge routers may install a default route to core routers, 91 to Area Border Routers (ABR) which are installed on the Point of 92 Presence (POP), to core boundary routers or to Autonomous System 93 Border Routers (ASBR). 95 S-VA must be enabled on an edge router that needs to save its RIB and 96 FIB space. The core routers must announce a new prefix called 97 virtual aggregate (VA-prefix). 99 1.1. Scope of this Document 101 The VA-prefix is not intended to be announced from one AS into 102 another, only between routers of the same AS. 104 S-VA can be used for IPv4 and IPv6 both unicast and multicast address 105 families. 107 S-VA need not operate on every router in an AS. 109 1.2. Requirements notation 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 1.3. Terminology 117 RIB/FIB-Installing Router (FIR): A router that does not suppress any 118 routes and announces the VA-prefix. Typically a core router, a 119 POP to core boundary router or an ASBR would be configured as an 120 FIR. 121 RIB/FIB-Suppressing Router (FSR): An S-VA router that installs the 122 VA-prefix, and does not install into its FIB routes that are 123 covered by and have the same next-hop as the VA-prefix. Typically 124 an edge router would be configured as an FSR. 126 Suppress: Not to install a route that is covered by the VA-prefix 127 into the global RIB or FIB 128 Legacy Router: A router that does not run S-VA, and has no knowledge 129 of S-VA. 130 Global Routing Information Base (RIB): All the routing protocols in 131 a router install their selected routes into the RIB. The routes 132 in the RIB are used to resolve next-hops for other routes, to be 133 redistributed to other routing protocols and to be installed into 134 the FIB. 135 Local/Protocol Routing Information Base (loc-RIB): The Loc-RIB 136 contains the routes that have been selected by the local BGP 137 speaker's Decision Process as in [RFC4271]. 138 NLRI: Network Layer Reachability Information [RFC4271] 140 2. Operation of S-VA 142 There are three types of routers in S-VA, FIB-Installing routers 143 (FIR), FIB-Suppressing routers (FSR) and optionally, legacy routers. 144 While any router can be an FIR or an FSR, the simplest form of 145 deployment is for AS border routers to be configured as FIRs and for 146 customer facing edge routers to be configured as FSRs. 148 When a FIR announces a VA-prefix, it sets the path attributes as 149 follows: The ORIGIN MUST be set to INCOMPLETE (value 2). The 150 NEXT_HOP MUST be set to the same as that of the routes which are 151 intended to be covered by the VA-prefix. The ATOMIC_AGGREGATE and 152 AGGREGATOR attributes SHOULD NOT be included. The FIR MUST attach a 153 NO_EXPORT Community Attribute [RFC1997]. The NLRI SHOULD be 0/0. 155 A FIR SHOULD NOT FIB-suppress any routes. 157 An FSR must detect the VA-prefix or prefixes (including 0/0) and 158 install them in all of Loc-RIB, RIB and FIB. The FSR MAY suppress 159 any more specific routes that carry the same next-hop as the VA- 160 prefix. 162 Generally, any more specific route which carries the same next-hop as 163 the VA-prefix is eligible for suppression. However, provided that 164 there is at least one less specific prefix with different next-hop 165 between the VA-prefix and the suppressed prefixes then those 166 suppressed prefixes must be reinstalled. 168 For example, consider 3 prefixes. VA-prefix is the least specific 169 and covers prefix2. prefix2 is less specific than prefix3 and covers 170 it. Like Russian dolls. If they all have the same next-hop, then 171 you can just send the biggest one with all the others inside. 172 However, if the middle one, prefix2 has a different next-hop, then 173 you have to take it out and send it separately. However, you must 174 remember to take out the smallest doll, prefix3 and also send it 175 separately. 177 Similarly, when IBGP multipath is enabled and when multiple VA 178 prefixes form a multipath, only those more specific prefixes of which 179 the set of next-hops are identical to the set of next-hops of the VA- 180 prefix multipath are subject to suppression. 182 The expected behavior is illustrated in Figure 1. This figure shows 183 an autonomous system with a FIR FIR1 and an FSR FSR1. FSR1 is an 184 ASBR and is connected to two external ASBRs, EP1 and EP2. 186 +------------------------------------------+ 187 | Autonomous System | +----+ 188 | | |EP1 | 189 | /---+---| | 190 | To ----\ +----+ +----+ / | +----+ 191 | Other \|FIR1|----------|FSR1|/ | 192 |Routers /| | | |\ | 193 | ----/ +----+ +----+ \ | +----+ 194 | \---+---|EP2 | 195 | | | | 196 | | +----+ 197 +------------------------------------------+ 198 Figure 1 200 Suppose that FSR1 has been enabled to perform S-VA. Originally it 201 receives all routes from FIR1 (doing next-hop-self) as well as from 202 EP1 and EP2. FIR1 now will advertise a VA prefix 0/0 with next-hop 203 set to itself. That will cause FSR1 to suppress all routes with the 204 same next-hop as the VA-prefix. However, FSR1 will not suppress any 205 routes received from EP1 and EP2, because their next-hops are 206 different from that of the VA-prefix. 208 Several FIRs may announce different S-VA prefixes. For example, in a 209 POP, each edge router can announce into the POP an S-VA prefix that 210 covers the addresses of the customers it services. 212 Several FIRs may announce the same S-VA prefix. In this case an FSR 213 must choose to install only one of them. For example, two redundant 214 ASBRs, both of which announce the complete DFRT may each also 215 announce the default route as an S-VA prefix into the AS. 217 S-VA may be used to split traffic among redundant exit routers. For 218 example, referring to Figure 1, suppose EP1 and EP2 are two redundant 219 ASBRs that announce the complete DFRT. Each may also announce two 220 S-VA prefixes into the AS: 0/1 and 128/1. EP1 might announce 0/1 221 with higher preference and EP2 might announce 128/1 with higher 222 preference. FIR1 will now install into is FIB 0/1 pointing to EP1 223 and 128/1 pointing to EP2. If either one of EP1 or EP2 were to fail, 224 then FSR1 would switch the traffic to the other exit router with a 225 single FIB installation of one S-VA prefix. 227 3. Deployment considerations 229 BGP routes may be used to resolve next-hops for static routes or 230 other BGP routes. Because the default route does not imply 231 reachability of any destination, a router can be configured not to 232 resolve next-hops using the default route. In this case, S-VA should 233 not suppress from installation into the RIB a route that may be used 234 to resolve a next-hop for another route. It may still suppress it 235 from installation into the FIB 237 Selected BGP routes in the RIB may be redistributed to other 238 protocols. If they no longer exist in the RIB, they will not be 239 redistributed. This is especially important when the conditional 240 redistribution is taking place based on the length of the prefix, 241 community value etc .. In those cases where redistribution policy is 242 in place S-VA code should refrain from suppressing from installation 243 into the RIB routes matching such policy. It may still suppress them 244 from installation into the FIB. 246 A router may originate a network route or an aggregate route into 247 BGP. Some addresses covered by such a route may not exist. If this 248 router were to receive a packet for an unreachable address within an 249 originated route, it must not send that packet to the VA-prefix 250 route. There are several ways to achieve this. One is to have the 251 FIR aggregate the routes instead of the FSR. Another is to install a 252 blackhole route for the nonexistent addresses on the originating 253 router. This issue is not specific to S-VA, but applicable to the 254 general use of default routes. 256 Like any aggregate, an S-VA prefix may include more address space 257 than the sum of the prefixes it covers. As such, the S-VA prefix may 258 provide a route for a packet for which no real destination exists. 259 An FSR will forward such a packet to the FIR. 261 If an S-VA prefix changes its next-hop or is removed, then many 262 routes may need to be downloaded into the FIB to achieve convergence. 264 4. IANA Considerations 266 There are no IANA considerations. 268 5. Security Considerations 270 The authors are not aware of any new security considerations due to 271 S-VA. 273 6. Acknowledgements 275 The concept for Virtual Aggregation comes from Paul Francis. In this 276 document authors only simplified some aspects of its behavior to 277 allow simpler adoption by some operators. 279 Authors would like to thank Clarence Filsfils, Nick Hilliard, S. 280 Moonesamy and Tom Petch for their review and valuable input. 282 7. References 284 7.1. Normative References 286 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 287 Communities Attribute", RFC 1997, August 1996. 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 293 Pignataro, "The Generalized TTL Security Mechanism 294 (GTSM)", RFC 5082, October 2007. 296 7.2. Informative References 298 [I-D.ietf-grow-va] 299 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 300 L. Zhang, "FIB Suppression with Virtual Aggregation", 301 draft-ietf-grow-va-06 (work in progress), December 2011. 303 Authors' Addresses 305 Robert Raszuk 306 NTT MCL 307 101 S Ellsworth Avenue Suite 350 308 San Mateo, CA 94401 309 US 311 Email: robert@raszuk.net 312 Jakob Heitz 313 Ericsson 314 300 Holger Way 315 San Jose, CA 95135 316 USA 318 Phone: 319 Email: jakob.heitz@ericsson.com 321 Alton Lo 322 Arista Networks 323 5470 Great America Parkway 324 Santa Clara, CA 95054 325 USA 327 Phone: 328 Email: altonlo@aristanetworks.com 330 Lixia Zhang 331 UCLA 332 3713 Boelter Hall 333 Los Angeles, CA 90095 334 US 336 Phone: 337 Email: lixia@cs.ucla.edu 339 Xiaohu Xu 340 Huawei Technologies 341 No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District 342 Beijing, Beijing 100085 343 P.R.China 345 Phone: +86 10 82836073 346 Email: xuxh@huawei.com