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