idnits 2.17.1 draft-wz-bess-evpn-vpws-as-vrf-ac-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8214], [RFC7432]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 160: '... But there SHOULD be no RT-2 adverti...' RFC 2119 keyword, line 161: '... [RFC8214]. So the RT-2 routes from PE2 to PE3 SHOULD not carry any...' RFC 2119 keyword, line 244: '...IP Advertisement SHOULD carry one EVI-...' RFC 2119 keyword, line 261: '... SHOULD be carried in VXLAN EVPN....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 'SHOULD not' in this paragraph: We use RT-2 routes to advertise the ARP entry of N1 from PE2 to PE3. But there SHOULD be no RT-2 advertisement in EVPN VPWS according to [RFC8214]. So the RT-2 routes from PE2 to PE3 SHOULD not carry any export-RTs of VPWS1, and the MPLS label1 field of these RT-2 routes should be set to NULL, not VPWS1. -- The document date (28 July 2021) is 1003 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4364' is mentioned on line 176, but not defined == Unused Reference: 'I-D.ietf-bess-srv6-services' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-inter-subnet-forwarding' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'RFC8365' is defined on line 408, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-07 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WG Y. Wang 3 Internet-Draft Z. Zhang 4 Intended status: Standards Track ZTE Corporation 5 Expires: 29 January 2022 28 July 2021 7 EVPN VPWS as VRF Attachment Circuit 8 draft-wz-bess-evpn-vpws-as-vrf-ac-01 10 Abstract 12 When a VRF Attachment Cirucit (VRF-AC) is far away from its IP-VRF 13 instance, we can deploy an EVPN VPWS ([RFC8214]) between that VRF-AC 14 and its IP-VRF instance. From the viewpoint of the IP-VRF instance, 15 a local virtual interface takes the place of that remote "VRF-AC". 16 The intended IP address for that VRF-AC is now configured to the 17 virtual interface, in other words, the virtual interface is the 18 actual VRF-AC of the IP-VRF instance. The virtual interface is also 19 the AC of that VPWS instance, in other words, the virtual interface 20 is cross-connected to that remote "VRF-AC" by the VPWS instance. 22 This document proposes an extension to [RFC7432] to support this 23 scenario. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 29 January 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Integrated Routing and Cross-connecting . . . . . . . . . 3 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. ARP/ND Synching and IP Prefix Synching . . . . . . . . . . . 5 62 2.1. Constructing MAC/IP Advertisement Route . . . . . . . . . 6 63 2.2. Constructing Ethernet A-D Route . . . . . . . . . . . . . 6 64 2.3. Constructing IP Prefix Advertisement Route . . . . . . . 7 65 3. Packet Walk Through . . . . . . . . . . . . . . . . . . . . . 7 66 4. Fast Convergence for Routed Traffic . . . . . . . . . . . . . 8 67 5. Considerations on ABRs and Route Reflectors . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 71 9. Informative References . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 When a VRF Attachment Cirucit (VRF-AC) is far away from its IP-VRF 77 instance, we can deploy an EVPN VPWS ([RFC8214]) between that VRF-AC 78 and its IP-VRF instance. From the viewpoint of the IP-VRF instance, 79 a local virtual interface takes the place of that remote "VRF-AC". 80 The intended IP address for that VRF-AC is now configured to the 81 virtual interface, in other words, the virtual interface is the 82 actual VRF-AC of the IP-VRF instance. The virtual interface is also 83 the AC of that VPWS instance, in other words, the virtual interface 84 is cross-connected to that remote "VRF-AC" by the VPWS instance. 86 The requirements of this scenario is described in Section 1.1. 88 1.1. Integrated Routing and Cross-connecting 90 When an IP-VRF instance and an EVPN VPWS instance are connected by an 91 virtual-interface, We call such scenarios as Integrated Routing and 92 Cross-connecting (IRC) use-case, and the virtual-interface connecting 93 EVPN VPWS and IP-VRF is called as IRC interface, because that the 94 packets received from the virtual-interface is routed in the IP-VRF 95 and the data packets sent to the virtual-interface is cross-connected 96 to the remote AC of that EVPN VPWS. 98 The IRC use case are illustrated by the following figure: 100 PE1 101 +---------------------+ 102 | IRC1=10.1 | 103 | +-----+ +------+ |. 104 .| |VPWS1|---|IPVRF1| | . 105 . | +-----+ +------+ | . 106 PE4 . | | . PE3 107 +--------+. +---------------------+ +---------+ 108 | | | | | 109 |+-----+ | | RT-2 |+------+ | 110 ||VPWS1| | | <10.2, N1> ||IPVRF1| | 111 |+-----+ | | label2=IPVRF1 |+------+ | 112 | | | | label1=VPWS1 | | | 113 +---|----+. | RT=VPWS1 .+---|-----+ 114 | . PE2 V . | 115 | . +---------------------+ . | 116 | .| IRC2=10.1 |. | 117 N1=10.2 | +-----+ +------+ | N2=20.2 118 | |VPWS1|---|IPVRF1| | 119 Behind N1: | +-----+ +------+ | 120 60.0/24 | | 121 70.0/24 +---------------------+ 123 Figure 1: ARP/ND Synchronizing for IRC Interfaces 125 There are four PE nodes named PE1/PE2/PE3/PE4 in the above network. 126 PE4 is a pure EVPN VPWS PE, there may be no IP-VRFs on it. PE3 is a 127 pure L3 EVPN PE, there may be no VPWSes or MAC-VRFs on it. PE1 and 128 PE2 are the border of the EVPN VPWS domain and the L3 EVPN domain, so 129 they are both EVPN VPWS PE and L3 EVPN PE, there will be both EVPN 130 IP-VRFs and EVPN VPWSes on them. 132 N1/N2/N3/N4 may be a host or an IP router. N1/N3/N4 is in the subnet 133 10.0/24. N2 is in the subnet 20.0/24. When N1/N2/N3/N4 is a host, 134 it is also called H1/H2/H3/H4 in this document. When N1/N2/N3/N4 is 135 a router, it is also called R1/R2/R3/R4 in this document. N1/N2/N3/ 136 N4's MAC address is M1/M2/M3/M4 respectively. 138 When N1 is a Router, there are two subnets behind N1, these subnets 139 are 60.0/24 and 70.0/24. 141 Note that there may be L2 switches between N1/N2/N3/N4 and their PEs. 142 These switches are not shown in Figure 1. 144 Note that the IRC interfaces are considered as AC interfaces in EVPN 145 VPWS instances. At the same time, they are considered as VRF-ACs in 146 IP-VRF instances. 148 When N1 sends an ARP Request REQ_P1, then REQ_P1 will be forwarded by 149 PE4 to either PE1 or PE2, not to the both. Both the IRC1 on PE1 and 150 IRC2 on PE2 are N1's subnet-gateway(SNGW). But when N2 send an ARP 151 Reply REP_P2 to N1, then PE3 may load-balance REP_P2 to either PE1 or 152 PE2, not to the both. 154 When REQ_P1 is load-balanced to PE1, not to PE2, but PE3 load-balance 155 REP_P2 to PE2, The ARP entry of N1 will not be prepared on PE2 for 156 REP_P2. So the fowarding of REP_P2 will be delayed due to ARP 157 missing. 159 We use RT-2 routes to advertise the ARP entry of N1 from PE2 to PE3. 160 But there SHOULD be no RT-2 advertisement in EVPN VPWS according to 161 [RFC8214]. So the RT-2 routes from PE2 to PE3 SHOULD not carry any 162 export-RTs of VPWS1, and the MPLS label1 field of these RT-2 routes 163 should be set to NULL, not VPWS1. 165 Note that an ESI may be assigned to IRC1 and IRC2, But it is not 166 necessary to advertise that ESI in the L3 EVPN domain. The ESI may 167 be advertised in the EVPN VPWS domain only. 169 1.2. Terminology 171 Most of the terminology used in this documents comes from [RFC7432] 172 and [I-D.ietf-bess-evpn-prefix-advertisement] except for the 173 following: 175 VRF AC: VRF Attachment Circuit, An Attachment Circuit (AC) that 176 attaches a CE to an IP-VRF. It is defined in [RFC4364]. 178 IRC: Integrated Routing and Cross-connecting, thus a IRC interface 179 is the virtual interface connecting an IP-VRF and an EVPN VPWS. 181 L3 EVI: An EVPN instance spanning the Provider Edge (PE) devices 182 participating in that EVPN which contains VRF ACs and maybe 183 contains IRB interfaces or IRC interfaces. 185 IP-AD/EVI: Ethernet Auto-Discovery route per EVI, and the EVI here 186 is an IP-VRF. 188 IP-AD/ES: Ethernet Auto-Discovery route per ES, and the EVI for 189 one of its route targets is an IP-VRF. 191 CE-BGP: The BGP session between PE and CE. Note that CE-BGP route 192 doesn't have a RD or Route-Target. 194 RMAC: Router's MAC, which is signaled in the Router's MAC extended 195 community. 197 RT-2E: A MAC/IP Advertisement Route with a non-reserved ESI. 199 RT-5E: An EVPN Prefix Advertisement Route with a non-reserved ESI. 201 RT-5G: An EVPN Prefix Advertisement Route with a zero ESI and a 202 non-zero GW-IP. 204 RT-5L: An EVPN Prefix Advertisement Route with both zero ESI and 205 zero GW-IP, but a valid MPLS label. 207 2. ARP/ND Synching and IP Prefix Synching 209 Host IP-MAC relations are learnt by PEs on the access side via a 210 control plane protocol like ARP. In case where N1 is multihomed to 211 multiple L3 EVPN PE nodes by an All-Active EVPN VPWS, N1's Host IP/ 212 MAC will be learnt and advertised in the MAC/IP Advertisement only by 213 the PE that receives the ARP packet. The MAC/ IP Advertisement with 214 non-zero ESI will be received by the other multihomed PEs. 216 As a result, after PE2 receives the MAC/IP Advertisement and imports 217 it to the VPWS Service Instance, PE2 installs an ARP entry to the 218 VPWS Service instance's IRC interface. Such ARP entry is called 219 remote synched ARP Entry in this document. 221 Note that the PE3 follows the DGW1 behavior of 222 [I-D.ietf-bess-evpn-prefix-advertisement]'s section 4.1 to achieve 223 the load balancing procedures based on the recursive route resolution 224 by the GW-IP Overlay Index. 226 When PE3 load balance the traffic towards PE1/PE2, both PE1 and PE2 227 would have been prepared with corresponding ARP entry yet because of 228 the following ARP synching procedures. 230 2.1. Constructing MAC/IP Advertisement Route 232 This draft introduces a new usage/construction of MAC/IP 233 Advertisement route to enable ARP/ND synching for IP addresses in 234 EVPN IRC use-cases. The usage/construction of this route remains 235 similar to that described in RFC 7432 with a few notable exceptions 236 as below. 238 * The Route-Distinguisher should be set to the corresponding EVPN- 239 VPWS context. 241 * The Ethernet Tag should be set to the VPWS Service Instance 242 Identifier of the IRC interface. 244 * The MAC/IP Advertisement SHOULD carry one EVI-RT (for the EVPN 245 VPWS instance) and one ES-Import RT (for the ESI of the IRC 246 interface). 248 * The ESI can be set to the ESI of the IRC interface. 250 Note that the receiver use the ESI and Ethernet Tag ID to 251 determine the VPWS Service Instance whose IRC interface is the 252 interface that the synced ARP entry will be installed to. 254 * The MPLS Label1 should be set to the label of the . 257 * The MPLS Label2 is optional. When it is used, it should be set to 258 IPVRF1. 260 * If the MPLS Label2 is used, the RMAC Extended Community attribute 261 SHOULD be carried in VXLAN EVPN. 263 2.2. Constructing Ethernet A-D Route 265 The ESI of the IRC interface is mainly used in the EVPN VPWS domain. 266 That ESI typically has nothing to do with the fundamental function of 267 the L3 EVPN domain. 269 Note that PE3 or PE4 will not import the RT-2 route with an ES-import 270 RT it doesn't recognize. 272 Note that the Ethernet A-D route advertisement in the EVPN VPWS 273 domain still follows [RFC8214]. The IRC interface is considered as 274 an ordinary AC in the EVPN VPWS domain. 276 2.3. Constructing IP Prefix Advertisement Route 278 There may be two types of IP prefixes on PE1/PE2. The first type is 279 the prefix of the IRC interface itself. The second type is the 280 prefixes behind N1 (especially when N1 is a router). 282 Given that PE1/PE2 can install synced ARP entries to its proper IRC 283 interface benefitting from the RT-2 route of Section 2. This ensures 284 that both PE1 and PE2 will know all hosts of the IRC interface's own 285 subnet. So it is not necessary for PE1/PE2 to advertise per-host IP 286 prefixes of that subnet to PE3 by RT-2 routes. It is recommended 287 that PE1/PE2 advertise a single RT-5 route of that subnet to PE3 288 instead. The ESI of these RT-5 routes can be simply set to zero, 289 because when PE3 receives such RT-5 routes from both PE1 and PE2, PE3 290 can consider them as ECMP or FRR even when their ESI is zero. 292 Note that N1 may be a host or a router, when it is a router, there 293 may be some prefixes behind N1 on PE1. Those prefixes will be learnt 294 via a PE-CE route protocol. N1's IP address may be considered as the 295 overlay nexthop of those prefixes. The overlay nexthop of those 296 prefixes will be carried in the RT-5 route's GW-IP field. Those RT-5 297 routes are called as RT-5G routes because their Overlay Indexes are 298 their GW-IPs (and their ESI and label are zero). 300 Note that those RT-5G routes are advertised by PE1 to both PE2 and 301 PE3. If the IRC1 interface fails, the prefixes of the second type 302 will achieve more faster convergency on PE3 by the withdraw (from 303 PE1) of the corresponding prefix of the first type. 305 3. Packet Walk Through 307 The procedures for local/remote host learning and MAC/IP 308 Advertisement route constructing are described above. 310 When R2(N2) send a data packet P21 to a host 60.1 whose location is 311 behind R1(N1), P21 will matches prefix 60.0/24 on PE3. The RT-5G 312 route for 60.0/24 will be used. The GW-IP of that RT-5G route is 313 10.1 (R1). So PE3 use 10.1 to do recursive route resolution and 314 matches the RT-5L route of 10.0/24. 316 Note that the recursive route resolution follows the DGW1 behavior of 317 [I-D.ietf-bess-evpn-prefix-advertisement]'s section 4.1. 319 Both PE1 and PE2 have advertised the RT-5L route of 10.0/24 to PE3. 320 PE3 may consider them as ECMP or FRR, depending on their route 321 attributes. Then PE3 should forward P21 to PE1 or PE2, depending on 322 the ECMP/FRR procedures. 324 We can assume that it is PE2 that will receive P21 from PE3. The 325 destination IP of P21 is in prefix 60.0/24. That prefix has been 326 installed into IPVRF1 on PE2. PE2 previously received that prefix 327 either from a PE-CE route protocol or from a RT-5G route from PE1. 328 The overlay nexthop or GW-IP of prefix 60.0/24 is 10.1 (R1). The 329 outgoing interface for P21 is IRC2 interface. 331 The ARP entry for 10.1 is a synched ARP entry, because PE1 sent the 332 ARP Request only to PE1. It is intalled to IRC2 interface just 333 because the RT-2 route's route target mathes the EVPN VPWS instance 334 and the RT-2 route's matches the IRC2 335 interfaces's ESI and VPWS Service Instance ID. 337 Then P21 is encapsulated with a ethernet header and becomes an 338 ethernet packet P21E. The destination MAC address of P21E is N1's 339 MAC address which is determined by that ARP entry. The source MAC 340 address of P21E is IRC2's MAC address. Then P21E is sent over IRC2 341 interface. 343 After P21E is sent over IRC2 interface, it will be forwarded to PE4 344 in the EVPN VPWS instance according to [RFC8214] 346 4. Fast Convergence for Routed Traffic 348 When IRC1 interface goes down, PE1 will withdraw the RT-5L route of 349 10.0/24. And the RT-5G routes of 60.0/24 and 70.0/24 will be just 350 changed to stale state. When PE3 receives the withdraw of that RT-5L 351 route, it will stop to forward the data packets of those two subnets 352 to PE1 again. But PE3 will continue to forward these data packets to 353 PE2. 355 5. Considerations on ABRs and Route Reflectors 357 When an ABR or ASBR receives a MAC/IP Advertisement Route that 358 contains both EVI-RT and ES-Import RT, It should re-advertise that 359 route even if that route's MPLS label1 is null (It should not 360 consider that route as malformed). When that route's nexthop are 361 changed to itself, It don't have to allocate a new label for each 362 RT-2 route's MPLS label1 field separately. That field can be 363 rewritten to the same preconfigured MPLS label that will blackhole 364 the data packets it received. But the MPLS label2 (if is not null) 365 field should be rewritten normally along with the nexthop-rewritting. 367 6. Security Considerations 369 This document does not introduce any new security considerations 370 other than already discussed in [RFC7432] and 371 [I-D.ietf-bess-evpn-prefix-advertisement]. 373 7. IANA Considerations 375 There is no IANA consideration needed. 377 8. Normative References 379 [I-D.ietf-bess-srv6-services] 380 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 381 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 382 Overlay Services", Work in Progress, Internet-Draft, 383 draft-ietf-bess-srv6-services-07, 11 April 2021, 384 . 387 [I-D.ietf-bess-evpn-prefix-advertisement] 388 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 389 Sajassi, "IP Prefix Advertisement in EVPN", Work in 390 Progress, Internet-Draft, draft-ietf-bess-evpn-prefix- 391 advertisement-11, 18 May 2018, 392 . 395 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 396 Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 397 Rabadan, "Integrated Routing and Bridging in EVPN", Work 398 in Progress, Internet-Draft, draft-ietf-bess-evpn-inter- 399 subnet-forwarding-15, 26 July 2021, 400 . 403 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 404 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 405 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 406 2015, . 408 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 409 Uttaro, J., and W. Henderickx, "A Network Virtualization 410 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 411 DOI 10.17487/RFC8365, March 2018, 412 . 414 9. Informative References 416 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 417 Rabadan, "Virtual Private Wire Service Support in Ethernet 418 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 419 . 421 Authors' Addresses 423 Yubao Wang 424 ZTE Corporation 425 No. 68 of Zijinghua Road, Yuhuatai Distinct 426 Nanjing 427 China 429 Email: wang.yubao2@zte.com.cn 431 Zheng(Sandy) Zhang 432 ZTE Corporation 433 No. 50 Software Ave, Yuhuatai Distinct 434 Nanjing 435 China 437 Email: zhang.zheng@zte.com.cn