idnits 2.17.1 draft-ietf-grow-simple-va-04.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 (September 15, 2011) is 4606 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-grow-va-05 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 A. Lo 5 Expires: March 18, 2012 Cisco 6 L. Zhang 7 UCLA 8 X. Xu 9 Huawei 10 September 15, 2011 12 Simple Virtual Aggregation (S-VA) 13 draft-ietf-grow-simple-va-04.txt 15 Abstract 17 The continued growth in the Default Free Routing Table (DFRT) 18 stresses the global routing system in a number of ways. One of the 19 most costly stresses is FIB size: ISPs often must upgrade router 20 hardware simply because the FIB has run out of space, and router 21 vendors must design routers that have adequate FIB. 23 FIB suppression is an approach to relieving stress on the FIB by NOT 24 loading selected RIB entries into the FIB. Simple Virtual 25 Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that 26 allows any and all edge routers to shrink their RIB and FIB 27 requirements substantially and therefore increase their useful 28 lifetime. 30 S-VA does not increase FIB requirements for core routers. S-VA is 31 extremely easy to configure considerably more so than the various 32 tricks done today to extend the life of edge routers. S-VA can be 33 deployed autonomously by an ISP (cooperation between ISPs is not 34 required), and can co-exist with legacy routers in the ISP. 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 March 18, 2012. 53 Copyright Notice 55 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . 5 72 1.2. Requirements notation . . . . . . . . . . . . . . . . . . . 5 73 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . . 6 75 3. Deployment considerations . . . . . . . . . . . . . . . . . . . 7 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 81 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 ISPs today manage constant DFRT growth in a number of ways. One way, 87 of course, is for ISPs to upgrade their router hardware before DFRT 88 growth outstrips the size of the FIB. This is too expensive for many 89 ISPs. They would prefer to extend the lifetime of routers whose FIBs 90 can no longer hold the full DFRT. 92 A common approach taken by lower-tier ISPs is to default route to 93 their providers. Routes to customers and peer ISPs are maintained, 94 but everything else defaults to the provider. This approach has 95 several disadvantages. First, packets to Internet destinations may 96 take longer-than-necessary AS paths. 98 This problem can be mitigated through careful configuration of 99 partial defaults, but this can require substantial configuration 100 overhead. A second problem with defaulting to providers is that the 101 ISP is no longer able to provide the full DFRT to its customers. 102 Finally, provider defaults prevents the ISP from being able to detect 103 martian packets. As a result, the ISP transmits packets that could 104 otherwise have been dropped over its expensive provider links. 106 An alternative is for the ISP to maintain full routes in its core 107 routers, but to filter routes from edge routers that do not require a 108 full DFRT. These edge routers can then default route to the core or 109 exit routers. This is often possible with edge routers that 110 interface to customer networks. The problem with this approach is 111 that it cannot be used for all edge routers. For instance, it cannot 112 be used for routers that connect to transits. It should also not be 113 used for routers that connect to customers which wish to receive the 114 full DFRT. 116 This draft describes a very simple technique, called Simple Virtual 117 Aggregation (S-VA), that allows any and all edge routers to have 118 substantially reduced FIB requirements even while still advertising 119 and receiving the full DFRT over BGP. The basic idea is as follows. 120 Core routers in the ISP maintain the full DFRT in the FIB and RIB. 121 Edge routers maintain the full DFRT in the BGP protocol RIB, but 122 suppress certain routes from being installed in RIB and FIB tables. 123 Edge routers install a default route to core routers, to ABRs which 124 are installed on the POP to core boundary or to the ASBR routers. 126 S-VA requires no changes to BGP and no changes to any choice of 127 forwarding mechanisms in routers. Configuration is extremely simple: 128 S-VA must be enabled on the edge router which needs to save it's RIB 129 and FIB space. In the same time operator must inject into his intra- 130 domain routing a new prefix further called virtual aggregate (VA- 131 prefix) which will be used as the aggregate forwarding reference by 132 the edge routers performing S-VA. Everything else is automatic. 133 ISPs can deploy FIB suppression autonomously and with no coordination 134 with neighbor ASes. 136 1.1. Scope of this Document 138 The scope of this document is limited to Intra-domain S-VA operation. 139 In other words, the case where a single ISP autonomously operates 140 S-VA internally without any coordination with neighboring ISPs. 142 Note that this document assumes that the S-VA "domain" (i.e. the unit 143 of autonomy) is the AS (that is, different ASes run S-VA 144 independently and without coordination). For the remainder of this 145 document, the terms ISP, AS, and domain are used interchangeably. 147 This document applies equally to IPv4 and IPv6 both unicast and 148 multicast address families. 150 S-VA may operate with a mix of upgraded routers and legacy routers. 151 There are no topological restrictions placed on the mix of routers. 152 S-VA functionality is local to the router on which it is enabled and 153 routing correctness is guaranteed. 155 Note that S-VA is a greatly simplified variant of "full VA" 156 [I-D.ietf-grow-va]. With full VA, all routers (core or otherwise) 157 can have reduced FIBs. However, full VA requires substantial new 158 configuration and operational complexity compared to S-VA. Full VA 159 also requires the use of MPLS LSPs between all routers. Note that 160 S-VA was formerly specified in [I-D.ietf-grow-va]. It has been moved 161 to this separate draft to simplify its understanding. 163 1.2. Requirements notation 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 1.3. Terminology 171 RIB/FIB-Installing Router (FIR): An router that does not suppress 172 any routes, and advertises itself as a default route for 0/0. 173 Typically a core router, POP to core boundary router or an ASBR 174 would be configured as an FIR. 175 RIB/FIB-Suppressing Router (FSR): An S-VA router that installs a 176 route to 0/0, and may suppress other routes. Typically an edge 177 router would be configured as an FSR. 179 Install and Suppress: The terms "install" and "suppress" are used to 180 describe whether a protocol local RIB entry has been loaded or not 181 loaded into the global RIB and FIB. In other words, the phrase 182 "install a route" means "install a route into the global RIB and 183 FIB", and the phrase "suppress a route" means "do not install a 184 route from BGP into the global RIB and FIB". 185 Legacy Router: A router that does not run S-VA, and has no knowledge 186 of S-VA. 187 Global Routing Information Base (RIB): The term global RIB is used 188 to indicate the router's main routing information base. That RIB 189 is normally used to populate FIB tables of the router. It needs 190 to be highlighted that unless FIB compression is used global RIB 191 and FIB tables are in sync. 192 Local/Protocol Routing Information Base (loc-RIB): The term local 193 RIB is used to indicate the protocol's table where product of SPF 194 or BGP best path selection is kept before being installed in 195 global RIB. In some protocol's implementations for example BGP 196 loc-RIB can be further divided into Adj-RIBs-In, the Loc-RIB, and 197 the Adj-RIBs-Out. 199 2. Operation of S-VA 201 There are three types of routers in S-VA, FIB-Installing routers 202 (FIR), FIB-Suppressing routers (FSR), and optionally legacy routers. 203 While any router can be an FIR or an FSR (there are no topology 204 constraints), the most simple form of deployment is for AS border or 205 POP border routers to be configured as FIRs, and for customer facing 206 edge routers respectively in the AS or in the POP to be configured as 207 FSRs. 209 FIRs must originate a default BGP route to NLRI 0/0 [RFC4271]. The 210 ORIGIN is set to INCOMPLETE (value 2) and the BGP NEXT_HOP is set to 211 match the other BGP routes which are also advertised by said FIR. 212 The ATOMIC_AGGREGATE and AGGREGATOR attributes are not included. The 213 FIR MUST attach a NO_EXPORT Community Attribute [RFC1997] to the 214 default route. 216 FIRs should not FIB-suppress any routes. They may, however, still 217 use some form of local FIB compression algorithm if deemed necessary. 219 FSRs must detect the VA prefix 0/0 and install it both in loc-RIB, 220 RIB and FIB. Following that FSR may suppres any more specific routes 221 which carry the same next hop as the VA prefix. To guarantee 222 semantical correctness FSR by default should also be able to detect 223 installation of not matching next hop route and reinstall all the 224 more specifics which were previously eligible for suppression to 225 maintain semantical forwarding correctness. 227 Generally, any more specific route which carries the same next hop as 228 the VA-prefix 0/0 is eligible for suppression. However, provided 229 that there was at least one less specific prefix (e.g., 1.0.0.0/8) 230 and the next-hop of such prefix was different from that of the VA 231 0/0, those more specific prefixes (e.g., 1.1.1.0/24) which are 232 otherwise subject to suppression would not be eligible for 233 suppression anymore. 235 Similarly when IBGP multipath is enabled and when multiple VA 236 prefixes are detected which are multipath candidates under given 237 network condition only those more specific prefixes are subject to 238 suppresion which have the identical set of next hops as multipath set 239 of VA prefixes. 241 Let's illustrate the expected behaviour on the figure below. This 242 figure shows an autonomous system with a FIR FIR1 and an FSR FSR1. 243 FSR1 is an ASBR and is connected to two remote ASBRs, EP1 and EP2. 245 +------------------------------------------+ 246 | Autonomous System | +----+ 247 | | |EP1 | 248 | /---+---| | 249 | To ----\ +----+ +----+ / | +----+ 250 | Other \|FIR1|----------|FSR1|/ | 251 |Routers /| | | |\ | 252 | ----/ +----+ +----+ \ | +----+ 253 | \---+---|EP2 | 254 | | | | 255 | | +----+ 256 +------------------------------------------+ 258 Suppose that FSR1 has been enabled to perform S-VA. Originally it 259 receives all routes from FIR1 (doing next hop self) as well as 260 directly connected EBGP peers EP1 and EP2. FIR1 now will advertise a 261 VA prefix 0/0 with next hop set to himself. That will trigger 262 detection of such prefix on FSR1 and suppression all routes which 263 have the same next hop as VA prefix and which otherwise would be 264 installed in RIB and FIB. However it needs to be observed that FSR1 265 will not suppres any EBGP routes received from his peers EP1 and EP2 266 due to next hop being different from the one assinged to VA-prefix. 268 3. Deployment considerations 270 The simplest deployment model of S-VA is it's use within the POP. In 271 such model the POP to core boundary routers (usually RRs in the data 272 path) would act as FIRs and would inject VA-prefix 0/0 to all of it's 273 clients within the POP. In such model of operation an observation 274 can be made that such ABRs do have full routing knowledge and client 275 to ABR distance is negligable as compared with client to intra-domain 276 exit distance. 278 Therefor under the above intra POP S-VA deployment model clients can 279 be configured that even in the event of lack of ABR to ABR 280 advertisement symmetry there is still no need to monitor if more 281 specific unsuppressed route would cover suppressed one. Thus in this 282 particular deployment model there is no need to detect and reinstall 283 the previously suppressed ones. 285 Another deploymet consideration should be given to networks which may 286 utilize route reflection. In the event of enabling IBGP multipath a 287 special care must be taken that both outbound prefixes as well as VA- 288 prefixes would pass via said route reflectors to their clients. 290 In order to addess the above aspects the following solutions could be 291 considered: 293 - Use of intra-POP S-VA 294 - Full mesh Small or medium side networks where S-VA can be deployed 295 are normally fully meshed and do not use route reflection. It 296 also needs to pointed out that some large networks are also fully 297 meshed today. 298 - Use of add-paths Use of add-paths new BGP encoding will allow to 299 distribute more then one overall best path from RR to each client. 300 - Alternate advertisement of VA-prefix S-VA prefix does not need to 301 be advertised in BGP. The BGP suppression will happen as long as 302 we configure the S-VA with next hop(s) and implementation verifies 303 that such VA-prefix is installed in the RIB and FIB. 305 4. IANA Considerations 307 There are no IANA considerations. 309 5. Security Considerations 311 The authors are not aware of any new security considerations due to 312 S-VA. 314 6. Acknowledgements 316 The concept for Virtual Aggregation comes from Paul Francis. In this 317 document authors only simplified some aspects of it's behaviour to 318 allow simpler adoption by some operators. 320 Authors would like to thank Clarence Filsfils for his valuable input. 322 7. References 324 7.1. Normative References 326 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 327 Communities Attribute", RFC 1997, August 1996. 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, March 1997. 332 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 333 Protocol 4 (BGP-4)", RFC 4271, January 2006. 335 7.2. Informative References 337 [I-D.ietf-grow-va] 338 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 339 L. Zhang, "FIB Suppression with Virtual Aggregation", 340 draft-ietf-grow-va-05 (work in progress), June 2011. 342 Authors' Addresses 344 Robert Raszuk 345 NTT MCL 346 101 S Ellsworth Avenue Suite 350 347 San Mateo, CA 94401 348 US 350 Email: robert@raszuk.net 352 Alton Lo 353 Cisco Systems, Inc. 354 170 West Tasman Drive 355 San Jose, CA 95134 356 USA 358 Phone: 359 Email: altonlo@cisco.com 360 Lixia Zhang 361 UCLA 362 3713 Boelter Hall 363 Los Angeles, CA 90095 364 US 366 Phone: 367 Email: lixia@cs.ucla.edu 369 Xiaohu Xu 370 Huawei Technologies 371 No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District 372 Beijing, Beijing 100085 373 P.R.China 375 Phone: +86 10 82836073 376 Email: xuxh@huawei.com