idnits 2.17.1 draft-wz-bess-evpn-vpws-as-vrf-ac-00.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 156: '... But there SHOULD be no RT-2 adverti...' RFC 2119 keyword, line 157: '... [RFC8214]. So the RT-2 routes from PE2 to PE3 SHOULD not carry any...' RFC 2119 keyword, line 239: '...IP Advertisement SHOULD carry one or m...' RFC 2119 keyword, line 256: '...munity attribute SHOULD be carried in ...' 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 (15 September 2020) is 1313 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 172, but not defined == Unused Reference: 'I-D.dawra-bess-srv6-services' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-inter-subnet-forwarding' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'RFC8365' is defined on line 403, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-10 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: 19 March 2021 15 September 2020 7 EVPN VPWS as VRF Attachment Circuit 8 draft-wz-bess-evpn-vpws-as-vrf-ac-00 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 19 March 2021. 42 Copyright Notice 44 Copyright (c) 2020 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 . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 8 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 71 9. Informative References . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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=NULL | | | 113 +---|----+. | .+---|-----+ 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. N1/N2/N3/N4 may be a host or an IP 131 router. N1/N3/N4 is in the subnet 10.0/24. N2 is in the subnet 132 20.0/24. When N1/N2/N3/N4 is a host, it is also called H1/H2/H3/H4 133 in this document. When N1/N2/N3/N4 is a router, it is also called 134 R1/R2/R3/R4 in this document. When N1 is a Router, there are two 135 subnets behind N1, these subnets are 60.0/24 and 70.0/24. 137 Note that there may be L2 switches between N1/N2/N3/N4 and their PEs. 138 These switches are not shown in Figure 1. 140 Note that the IRC interfaces are considered as AC interfaces in EVPN 141 VPWS instances. At the same time, they are considered as VRF-ACs in 142 IP-VRF instances. 144 When N1 sends an ARP Request REQ_P1, then REQ_P1 will be forwarded by 145 PE4 to either PE1 or PE2, not to the both. Both the IRC1 on PE1 and 146 IRC2 on PE2 are N1's subnet-gateway(SNGW). But when N2 send an ARP 147 Reply REP_P2 to N1, then PE3 may load-balance REP_P2 to either PE1 or 148 PE2, not to the both. 150 When REQ_P1 is load-balanced to PE1, not to PE2, but PE3 load-balance 151 REP_P2 to PE2, The ARP entry of N1 will not be prepared on PE2 for 152 REP_P2. So the fowarding of REP_P2 will be delayed due to ARP 153 missing. 155 We use RT-2 routes to advertise the ARP entry of N1 from PE2 to PE3. 156 But there SHOULD be no RT-2 advertisement in EVPN VPWS according to 157 [RFC8214]. So the RT-2 routes from PE2 to PE3 SHOULD not carry any 158 export-RTs of VPWS1, and the MPLS label1 field of these RT-2 routes 159 should be set to NULL, not VPWS1. 161 Note that an ESI may be assigned to IRC1 and IRC2, But it is not 162 necessary to advertise that ESI in the L3 EVPN domain. The ESI may 163 be advertised in the EVPN VPWS domain only. 165 1.2. Terminology 167 Most of the terminology used in this documents comes from [RFC7432] 168 and [I-D.ietf-bess-evpn-prefix-advertisement] except for the 169 following: 171 VRF AC: VRF Attachment Circuit, An Attachment Circuit (AC) that 172 attaches a CE to an IP-VRF. It is defined in [RFC4364]. 174 IRC: Integrated Routing and Cross-connecting, thus a IRC interface is 175 the virtual interface connecting an IP-VRF and an EVPN VPWS. 177 L3 EVI: An EVPN instance spanning the Provider Edge (PE) devices 178 participating in that EVPN which contains VRF ACs and maybe contains 179 IRB interfaces or IRC interfaces. 181 IP-AD/EVI: Ethernet Auto-Discovery route per EVI, and the EVI here is 182 an IP-VRF. 184 IP-AD/ES: Ethernet Auto-Discovery route per ES, and the EVI for one 185 of its route targets is an IP-VRF. 187 CE-BGP: The BGP session between PE and CE. Note that CE-BGP route 188 doesn't have a RD or Route-Target. 190 RMAC: Router's MAC, which is signaled in the Router's MAC extended 191 community. 193 RT-2E: A MAC/IP Advertisement Route with a non-reserved ESI. 195 RT-5E: An EVPN Prefix Advertisement Route with a non-reserved ESI. 197 RT-5G: An EVPN Prefix Advertisement Route with a zero ESI and a non- 198 zero GW-IP. 200 RT-5L: An EVPN Prefix Advertisement Route with both zero ESI and zero 201 GW-IP, but a valid MPLS label. 203 2. ARP/ND Synching and IP Prefix Synching 205 Host IP-MAC relations are learnt by PEs on the access side via a 206 control plane protocol like ARP. In case where N1 is multihomed to 207 multiple L3 EVPN PE nodes by an All-Active EVPN VPWS, N1's Host IP/ 208 MAC will be learnt and advertised in the MAC/IP Advertisement only by 209 the PE that receives the ARP packet. The MAC/ IP Advertisement with 210 non-zero ESI will be received by the other multihomed PE. 212 As a result, after PE2 receives the MAC/IP Advertisement and imports 213 it to the L3 EVI, PE2 installs an ARP entry to the VRF interface 214 whose subnet matches the IP Address from the MAC/IP Advertisement. 215 Such ARP entry is called remote synched ARP Entry in this document. 217 Note that the PE3 follows the DGW1 behavior of 218 [I-D.ietf-bess-evpn-prefix-advertisement]'s section 4.3 to achieve 219 the load balancing procedures based on the recursive route resolution 220 by the ESI Overlay Index. 222 When PE3 load balance the traffic towards PE1/PE2, both PE1 and PE2 223 would have been prepared with corresponding ARP entry yet because of 224 the following ARP synching procedures. 226 2.1. Constructing MAC/IP Advertisement Route 228 This draft introduces a new usage/construction of MAC/IP 229 Advertisement route to enable ARP/ND synching for IP addresses in 230 EVPN IRC use-cases. The usage/construction of this route remains 231 similar to that described in RFC 7432 with a few notable exceptions 232 as below. 234 * The Route-Distinguisher should be set to the corresponding IP-VRF 235 context. 237 * The Ethernet Tag should be set to 0. 239 * The MAC/IP Advertisement SHOULD carry one or more IP VRF Route- 240 Target (RT) attributes. 242 * The ESI can be simply set to zero. 244 Note that we use the subnet consistency between the host IP 245 address and the IRC interface to determine which interface the 246 synched ARP/ND entry should be installed to. 248 * The MPLS Label1 should be set to NULL. 250 Note that the NULL value of MPLS label1 in MPLS EVPN should be 251 implicit-null. The NULL value of MPLS label1 in VXLAN EVPN should 252 be 0. 254 * The MPLS Label2 should be set to IPVRF1. 256 * The RMAC Extended Community attribute SHOULD be carried in VXLAN 257 EVPN. 259 2.2. Constructing Ethernet A-D Route 261 The ESI of the IRC interface is mainly use in the EVPN VPWS domain. 262 That ESI has nothing to do with the fundamental function of the L3 263 EVPN domain. 265 Note that the Ethernet A-D route advertisement in the EVPN VPWS 266 domain still follows [RFC8214]. The IRC interface is considered as 267 an ordinary AC in the EVPN VPWS domain. 269 2.3. Constructing IP Prefix Advertisement Route 271 There may be two types of IP prefixes on PE1/PE2. The first type is 272 the prefix of the IRC interface itself. The second type is the 273 prefixes behind N1 (especially when N1 is a router). 275 Given that PE1/PE2 can install synced ARP entries to its proper IRC 276 interface benefitting from the RT-2 route of Section 2. This ensures 277 that both PE1 and PE2 will know all hosts of the IRC interface's own 278 subnet. So it is not necessary for PE1/PE2 to advertise per-host IP 279 prefixes of that subnet to PE3 by RT-2 routes. It is recommended 280 that PE1/PE2 advertise a single RT-5 route of that subnet to PE3 281 instead. The ESI of these RT-5 routes can be simply set to zero, 282 because when PE3 receives such RT-5 routes from both PE1 and PE2, PE3 283 can consider them as ECMP or FRR even when their ESI is zero. 285 Note that N1 may be a host or a router, when it is a router, there 286 may be some prefixes behind N1 on PE1. Those prefixes will be learnt 287 via a PE-CE route protocol. N1's IP address may be considered as the 288 overlay nexthop of those prefixes. The overlay nexthop of those 289 prefixes will be carried in the RT-5 route's GW-IP field. Those RT-5 290 routes are called as RT-5G routes because their Overlay Indexes are 291 their GW-IPs (and their ESI and label are zero). 293 Note that those RT-5G routes are advertised by PE1 to both PE2 and 294 PE3. If the IRC1 interface fails, the prefixes of the second type 295 will achieve more faster convergency on PE3 by the withdraw (from 296 PE1) of the corresponding prefix of the first type. 298 3. Packet Walk Through 300 The procedures for local/remote host learning and MAC/IP 301 Advertisement route constructing are described above. 303 When R2(N2) send a data packet P21 to a host 60.1 whose location is 304 behind R1(N1), P21 will matches prefix 60.0/24 on PE3. The RT-5G 305 route for 60.0/24 will be used. The GW-IP of that RT-5G route is 306 10.1 (R1). So PE3 use 10.1 to do recursive route resolution and 307 matches the RT-5L route of 10.0/24. 309 Note that the recursive route resolution follows the DGW1 behavior of 310 [I-D.ietf-bess-evpn-prefix-advertisement]'s section 4.1. 312 Both PE1 and PE2 have advertised the RT-5L route of 10.0/24 to PE3. 313 PE3 may consider them as ECMP or FRR, depending on their route 314 attributes. Then PE3 should forward P21 to PE1 or PE2, depending on 315 the ECMP/FRR procedures. 317 We can assume that it is PE2 that will receive P21 from PE3. The 318 destination IP of P21 is in prefix 60.0/24. That prefix has been 319 installed into IPVRF1 on PE2. PE2 previously received that prefix 320 either from a PE-CE route protocol or from a RT-5G route from PE1. 321 The overlay nexthop or GW-IP of prefix 60.0/24 is 10.1 (R1). The 322 outgoing interface for P21 is IRC2 interface. 324 The ARP entry for 10.1 is a synched ARP entry, because PE1 sent the 325 ARP Request only to PE1. It is intalled to IRC2 interface just 326 because it is the ARP entry of a host of IRC2's subnet. 328 Then P21 is encapsulated with a ethernet header and becomes an 329 ethernet packet P21E. The destination MAC address of P21E is N1's 330 MAC address which is determined by that ARP entry. The source MAC 331 address of P21E is IRC2's MAC address. Then P21E is sent to IRC2 332 interface. 334 After P21E is sent to IRC2 interface, it will be forwarded to PE4 in 335 the EVPN VPWS instance according to [RFC8214] 337 4. Fast Convergence for Routed Traffic 339 When IRC1 interface goes down, PE1 will withdraw the RT-5L route of 340 10.0/24. And the RT-5G routes of 60.0/24 and 70.0/24 will be just 341 changed to stale state. When PE3 receives the withdraw of that RT-5L 342 route, it will stop to forward the data packets of those two subnets 343 to PE1 again. 345 5. Considerations on ABRs and Route Reflectors 347 When a Route Reflector (RR) receives a MAC/IP Advertisement Route 348 whose MPLS label1 field is NULL, It should reflect that route to its 349 clients as a normal route. It should not consider that route as 350 malformed. 352 When a ABR or ASBR receives a MAC/IP Advertisement Route whose MPLS 353 label1 field is NULL, It should re-advertise that route and that 354 route's nexthop will be changed to itself. It should not consider 355 that route as malformed. It should not allocate a new label for the 356 MPLS label1 field. That field should be kept NULL during the re- 357 advertisement. But the MPLS label2 field should be rewritten along 358 with the nexthop-rewritting. 360 6. Security Considerations 362 This document does not introduce any new security considerations 363 other than already discussed in [RFC7432] and 364 [I-D.ietf-bess-evpn-prefix-advertisement]. 366 7. IANA Considerations 368 There is no IANA consideration needed. 370 8. Normative References 372 [I-D.dawra-bess-srv6-services] 373 Dawra, G., Filsfils, C., Brissette, P., Agrawal, S., 374 Leddy, J., daniel.voyer@bell.ca, d., 375 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 376 Decraene, B., Matsushima, S., Zhuang, S., and J. Rabadan, 377 "SRv6 BGP based Overlay services", Work in Progress, 378 Internet-Draft, draft-dawra-bess-srv6-services-02, 8 July 379 2019, . 382 [I-D.ietf-bess-evpn-prefix-advertisement] 383 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 384 Sajassi, "IP Prefix Advertisement in EVPN", Work in 385 Progress, Internet-Draft, draft-ietf-bess-evpn-prefix- 386 advertisement-11, 18 May 2018, 387 . 390 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 391 Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 392 Rabadan, "Integrated Routing and Bridging in EVPN", Work 393 in Progress, Internet-Draft, draft-ietf-bess-evpn-inter- 394 subnet-forwarding-10, 3 September 2020, 395 . 398 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 399 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 400 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 401 2015, . 403 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 404 Uttaro, J., and W. Henderickx, "A Network Virtualization 405 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 406 DOI 10.17487/RFC8365, March 2018, 407 . 409 9. Informative References 411 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 412 Rabadan, "Virtual Private Wire Service Support in Ethernet 413 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 414 . 416 Authors' Addresses 417 Yubao Wang 418 ZTE Corporation 419 No. 68 of Zijinghua Road, Yuhuatai Distinct 420 Nanjing 421 China 423 Email: yubao.wang2008@hotmail.com 425 Zheng(Sandy) Zhang 426 ZTE Corporation 427 No. 50 Software Ave, Yuhuatai Distinct 428 Nanjing 429 China 431 Email: zzhang_ietf@hotmail.com