idnits 2.17.1 draft-wang-idr-vpn-routes-control-analysis-02.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 33 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 8, 2021) is 1137 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group8 A. Wang 3 Internet-Draft W. Wang 4 Intended status: Informational China Telecom 5 Expires: September 9, 2021 G. Mishra 6 Verizon Inc. 7 H. Wang 8 S. Zhuang 9 J. Dong 10 Huawei Technologies 11 March 8, 2021 13 Analysis of VPN Routes Control in Shared BGP Session 14 draft-wang-idr-vpn-routes-control-analysis-02 16 Abstract 18 This draft analyzes some scenarios and the necessaries for VPN routes 19 control in the shared BGP session, which can be the used as the base 20 for the design of related solutions. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 9, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 2 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 4. Inter-AS VPN Option B/AB Scenario . . . . . . . . . . . . . . 3 60 5. Inter-AS VPN Option C Scenario . . . . . . . . . . . . . . . 4 61 6. Intra-AS VPN RR Deployment Scenario . . . . . . . . . . . . . 5 62 7. VPN Routes Shared on one PE . . . . . . . . . . . . . . . . . 6 63 8. Requirements for the solutions . . . . . . . . . . . . . . . 7 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 67 12. Normative References . . . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 BGP Maximum Prefix feature [RFC4486] is often used at the network 73 boundary to control the number of prefixes to be injected into the 74 network. But for some scenarios when the VPN routes from several 75 VRFs are advertised via one shared BGP session, there is lack of 76 appropriate methods to control the flooding of VPN routes within one 77 VRF to overwhelm the process of VPN routes in other VRFs. That is to 78 say, the excessive VPN routes advertisement should be controlled 79 individually for each VRF in such shared BGP session. 81 The following sections analyzes the scenarios that are necessary to 82 such mechanism. 84 2. Conventions used in this document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119] . 90 3. Terminology 92 The following terms are defined in this draft: 94 o RD: Route Distinguisher, defined in [RFC4364] 95 o RR: Router Reflector, provides a simple solution to the problem of 96 IBGP full mesh connection in large-scale IBGP implementation. 98 o VRF: Virtual Routing Forwarding, a virtual routing table based on 99 VPN instance. 101 4. Inter-AS VPN Option B/AB Scenario 103 For inter-AS VPN deployment option B/AB scenario, as described in 104 Figure 1, there is one BGP session between ASBR1 and ASBR2, which is 105 used to advertise the VPN routes from VPN1 and VPN2 VRF. Normally 106 the operator will deploy the BGP maximum prefixes feature under 107 different address families between the ASBR1 and ASBR2, but the 108 threshold must be set very high to cope with the situation when all 109 the VRFs in each family reach their VPN routes limit simultaneously. 110 In case VPN routes in only one of VRF, for example VPN1 in PE3, 111 advertises excess VPN routes(with RD set to RD31 and RT import/export 112 set to RT1. Configurations on other PEs are similar) into the 113 network, but VPN routes advertisement in other VRFs are in normal, 114 the prefix bar set between the ASBRs will not take effect. Such 115 excessive VPN routes will be advertised into the AS1, to PE1 and PE2 116 respectively. 118 PE1 in this example, provides the services for VPN2 at the same time. 119 If it receives the excessive VPN routes for VPN1 from ASBR1, although 120 such VPN routes have exceeded the limit within the VRF VPN1, it can't 121 break the BGP session with ASBR1 directly, because the VPN prefix 122 limit is to prevent a flood from errors or other issues but does not 123 prevent the device from being overwhelmed and resources exhausted. 125 All it can do is to receive and process the excessive BGP updates 126 continuously, parse the excessive VPN routes for VPN1 and drop it, 127 extract the VPN routes for VPN2 and install it. 129 Doing so can certainly influence the performance of PE1 to serve the 130 other VPN services on it, considering that there are hundreds of VRFs 131 deployed on it. 133 PE1 should have the capability to control the advertisement of 134 specified excessive VPN routes from its BGP peer. The ASBR should 135 also have such capability. 137 The excessive VPN routes may carry just one RT(for example in VPN1 on 138 PE3), or carry more than one RTs(for example in VPN2 on PE3). Such 139 excessive VPN routes may be imported into one VRF(for example VPN1 on 140 PE1) or more than one VRFs(for example both VPN2 and VPN3 import the 141 VPN routes with RD32, which has attached RT2 and RT3 together when 142 they are advertised) 144 +---------------------------+ +------------------------------+ 145 | | | | 146 | | | | 147 | +---------+ | | +---------+ | 148 | | PE1 | | | | PE3 | | 149 | +---------+ | | +---------+ | 150 |VPN1(RD11,RT1)\ | | /VPN1(RD31,RT1) | 151 |VPN2(RD12,RT2) \+---------+ MP-EBGP +---------+/ VPN2(RD32,RT2,RT3)| 152 |VPN3(RD3 ,RT3) | | | | | 153 | | ASBR1 |-----------| ASBR2 | | 154 | | | | | | 155 | +---------+ +---------+ | 156 | / | | \ | 157 | +---------+/ | | \+---------+ | 158 | | PE2 | | | | PE4 | | 159 | +---------+ | | +---------+ | 160 |VPN1(RD21,RT1) | | VPN2(RD42,RT2) | 161 |VPN2(RD2 ,RT2) | | VPN3(RD3, RT3) | 162 | AS1 | | AS2 | 163 +---------------------------+ +------------------------------+ 165 Figure 1: The Option B/Option AB cross-domain scenario 167 5. Inter-AS VPN Option C Scenario 169 For inter-AS VPN deployment option C scenario, as that described in 170 Figure 2, there is one BGP session between RR1 and RR2, which is used 171 to advertise the VPN routes from all the VRFs that located on the 172 edge routers(PE1 and PE2). The BGP maximum prefix bar can't also 173 prevent the excessive advertisement of VPN routes in one VRF, and 174 such abnormal behavior in one VRF can certainly influence the 175 performances of PEs to serve other normal VRFs. 177 PE and RR should all have some capabilities to control the specified 178 excessive VPN routes to be advertised from its upstream BGP peer. 180 MP-EBGP 181 +------------------------------------------+ 182 | | 183 +------------+--------------+ +------------+------------------+ 184 | +---+----+ | | +----+----+ | 185 | +---+ RR1 +---+ | | +----+ RR2 +---+ | 186 | | +--------+ | | | | +---------+ | | 187 | | | | | | | | 188 | |IBGP IBGP| | | |IBGP IBGP| | 189 | | | | | | | | 190 | +--+---+ +---+--+ | | +---+---+ +--+--+ | 191 | | PE1 | | ASBR1|--|--------------|---| ASBR2 | | PE2 | | 192 | +------+ +------+ | | +-------+ +-----+ | 193 | AS1 | | AS2 | 194 +---------------------------+ +-------------------------------+ 196 Figure 2: The Option C cross-domain scenario 198 6. Intra-AS VPN RR Deployment Scenario 200 For intra-AS VPN deployment, as depicted in Figure 3, if the RR is 201 present, the above excess VPN routes advertisement churn can also 202 occurs. For example, if PE3 receives excessive VPN routes for VPN1 203 VRF(there may be several reasons for this to occur, for example, 204 multiple CEs connect to PE3 advertising routes simultaneously causing 205 a wave of routes, redistribution from VRF to VRF, or from GRT to VRF 206 on PE3 etc.), it will advertise such excessive VPN routes to RR and 207 then to PE1. The BGP session between RR and PE3, and the BGP session 208 between RR and PE1 can't prevent this to occur. 210 The RD in each VPN may be allocated and unique for each VPN on each 211 PE(as example VPN1 in Figure 3), or only unique for each VPN(as 212 example VPN2 in Figure 3). 214 Each VPN may be associated with one or more RTs. The excessive VPN 215 routes may have only one RT(for example, the excessive VPN routes 216 from PE3 has the RD equal to RD31 and RT is set only to RT1) 218 When PE1 in this figure receives such excessive VPN routes, it can 219 only process them, among the other normal BGP updates. This can 220 certainly influence process of VPN routes for other normal services, 221 the consequences on the receiving PE1 may be the one or more of the 222 followings: 224 a) PE1 can't process a given number of routes in time period X 225 leading to dropping of routes 226 b) Delayed processing that may result in an incomplete number of 227 inputs to the BGP Best Path decision. 229 c) L3VPN customers experiencing an incorrect VPN specification for 230 some time period Y. 232 d) The convergence of control plane processing impacts the traffic 233 forwarding 235 PE and RR should all have some capabilities to control the specified 236 excessive VPN routes to be advertised from its upstream BGP peer. 238 +-----------------------------------------------+ 239 | +---------+ +---------+ | 240 | | PE1 | | PE4 | | 241 | +---------+ +---------+ | 242 | VPN1(RD11,RT1) \ / VPN2(RD12,RT2)| 243 | VPN2(RD12,RT2) \+---------+ / | 244 | | | | 245 | | RR | | 246 | | | | 247 | +---------+ \ | 248 | / \ | 249 | +---------+/ +---------+ | 250 | | PE2 | | PE3 | | 251 | +---------+ +---------+ | 252 | VPN1(RD21,RT1) VPN1(RD31,RT1,RT2)| 253 | VPN2(RD12,RT2) | 254 | | 255 | AS100 | 256 +-----------------------------------------------+ 258 Figure 3: Intra-AS VPN RR deployment scenario 260 7. VPN Routes Shared on one PE 262 The scenarios described above are mainly in device level, that is to 263 say, if the receiving PE has some mechanism to control the excess VPN 264 routes advertisement from its BGP neighbor, the failure churn effect 265 can be controlled then. But there are also situations that the 266 granular control should be took place within the receiving PE itself. 268 Figure 4 below describes such scenario. There are four VRFs on PE, 269 and three of them import the same VPN routes that carry route target 270 RT3. Such deployment can occur in the inter-VRF communication 271 scenario. If the threshold of VPN route-limit for these VRFs is set 272 different, for example, are max-vpn-routes-vrf1, max-vpn-routes-vrf2, 273 max-vpn-routes-vrf3, max-vpn-routes-vrf4 respectively, and these 274 values have the following order, as max-vpn-routes-vrf1. 356 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 357 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 358 2006, . 360 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 361 Notification Message", RFC 4486, DOI 10.17487/RFC4486, 362 April 2006, . 364 Authors' Addresses 365 Aijun Wang 366 China Telecom 367 Beiqijia Town, Changping District 368 Beijing, Beijing 102209 369 China 371 Email: wangaj3@chinatelecom.cn 373 Wei Wang 374 China Telecom 375 Beiqijia Town, Changping District 376 Beijing, Beijing 102209 377 China 379 Email: wangw36@chinatelecom.cn 381 Gyan S. Mishra 382 Verizon Inc. 383 13101 Columbia Pike 384 Silver Spring MD 20904 385 United States of America 387 Phone: 301 502-1347 388 Email: gyan.s.mishra@verizon.com 390 Haibo Wang 391 Huawei Technologies 392 Huawei Building, No.156 Beiqing Rd. 393 Beijing, Beijing 100095 394 China 396 Email: rainsword.wang@huawei.com 398 Shunwan Zhuang 399 Huawei Technologies 400 Huawei Building, No.156 Beiqing Rd. 401 Beijing, Beijing 100095 402 China 404 Email: zhuangshunwan@huawei.com 405 Jie Dong 406 Huawei Technologies 407 Huawei Building, No.156 Beiqing Rd. 408 Beijing, Beijing 100095 409 China 411 Email: jie.dong@huawei.com