idnits 2.17.1 draft-wang-bess-evpn-arp-nd-synch-without-irb-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([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 186: '...IP Advertisement SHOULD carry one or m...' RFC 2119 keyword, line 189: '... * The ESI SHOULD be set to the ESI ...' RFC 2119 keyword, line 206: '...6 L3 Service TLV MAY also be advertise...' RFC 2119 keyword, line 211: '...munity attribute SHOULD be carried in ...' RFC 2119 keyword, line 229: '...n L3 Service SID MAY also be advertise...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 28, 2019) is 1610 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) == Unused Reference: 'I-D.ietf-bess-evpn-prefix-advertisement' is defined on line 331, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-sajassi-bess-evpn-ip-aliasing-00 Summary: 2 errors (**), 0 flaws (~~), 3 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: May 31, 2020 November 28, 2019 7 ARP/ND Synching And IP Aliasing without IRB 8 draft-wang-bess-evpn-arp-nd-synch-without-irb-02 10 Abstract 12 This draft proposes an extension to [RFC7432] to do ARP synchronizing 13 and IP aliasing for Layer 3 routes that is needed for pure L3 EVPN to 14 build a complete IP ECMP. The phrase "pure L3 EVPN" means that there 15 is no MAC-VRF or IRB interface in the use case. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 31, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. ARP/ND Synching and IP Aliasing . . . . . . . . . . . . . . . 3 54 2.1. Constructing MAC/IP Advertisement Route . . . . . . . . . 4 55 2.2. Constructing EAD/IP-VRF Route . . . . . . . . . . . . . . 5 56 2.3. Constructing EAD/ES Route . . . . . . . . . . . . . . . . 5 57 3. Fast Convergence for Routed Traffic . . . . . . . . . . . . . 6 58 4. Determining Reach-ability to Unicast IP Addresses . . . . . . 6 59 5. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . 6 60 6. Use RT-5 Route with ESI to Reduce Route Advertisement . . . . 7 61 7. Load Balancing of Unicast Packets . . . . . . . . . . . . . . 7 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 [I-D.sajassi-bess-evpn-ip-aliasing] proposes an extension to 70 [RFC7432] to do aliasing for Layer 3 routes that is needed for 71 symmetric IRB to build a complete IP ECMP. But typically there may 72 be both IRB interfaces(to do EVPN IRB per-MAC-VRF basis) and VRF- 73 interfaces in the same IP-VRF instance. It is necessary to apply the 74 EVPN control-plane to the VRF-interfaces in order to support both 75 such situations and the pure L3 EVPN use case where no IRB interfaces 76 will be found in the IP-VRF instances. 78 +---------+ 79 +-------------+ | | 80 | | | | 81 /| PE1 |----| | +-------------+ 82 / | | | MPLS/ | | | 83 LAG / +-------------+ | VxLAN/ | | PE3 |---H3 84 H1---SW1===== | NVGRE/ | | | 85 / \ +-------------+ | SRv6 |---| | 86 H2 \ | | | | +-------------+ 87 \| PE2 |----| | 88 | | | | 89 +-------------+ | | 90 | | 91 | | 92 +---------+ 94 Figure 1: ARP/ND Synchronizing and IP Aliasing without IRB 96 Consider a pair of multi-homed PEs PE1 and PE2. Let there be two 97 hosts H1 and H2 attached to them via a L2 switch SW1. Consider 98 another PE PE3 and a host H3 attached to it. The H1 and H2 represent 99 subnet SN1 and the H3 represents subnet SN2. 101 Note that it is different from [I-D.sajassi-bess-evpn-ip-aliasing] in 102 the following aspects: There is no MAC-VRF or IRB interface on 103 PE1/PE2/PE3. And it is the IP-VRFs that are called as EVPN instance 104 instead. Such EVPN instance can be called pure L3 EVPN instance or 105 L3 EVI for short. The anycast gateway of H1/H2 is configured on a 106 sub-interface on PE1/PE2. 108 Note that the communication between H1 and H2 won't pass through any 109 of the multi-homed PEs. So it is not necessary for PE1/PE2 keeping a 110 Broadcast domain and its IRB for SN1. 112 Note that the SW1 multi-homing PE1 and PE2 via a LAG interface which 113 maybe load-balance traffic to the PEs. 115 This draft proposes an extension to do ARP/ND synchronizing and IP 116 aliasing for Layer 3 routes that is needed for L3 EVI to build a 117 complete IP ECMP. 119 1.1. Terminology 121 Most of the terminology used in this documents comes from [RFC7432] 122 and [I-D.sajassi-bess-evpn-ip-aliasing] except for the following: 124 VRF Interface: A interface that connects to a CE for an IP-VRF but is 125 not an IRB interface. 127 L3 EVI: An EVPN instance spanning the Provider Edge (PE) devices 128 participating in that EVPN which contains VRF Interfaces and maybe 129 contains IRB interfaces. 131 EAD/IP-VRF: Ethernet Auto-Discovery route per IP-VRF, which 132 differentiates itself from IP-EAD/EVI route by the MPLS label field. 134 RMAC: Router's MAC, which is signaled in the Router's MAC extended 135 community. 137 2. ARP/ND Synching and IP Aliasing 139 Host IP and MAC routes are learnt by PEs on the access side via a 140 control plane protocol like ARP. In case where a CE is multihomed to 141 multiple PE nodes using a LAG and is running in All-Active Redundancy 142 Mode, the Host IP will be learnt and advertised in the MAC/IP 143 Advertisement only by the PE that receives the ARP packet. The MAC/ 144 IP Advertisement with non-zero ESI will be received by both PE2 and 145 PE3. 147 As a result, after PE2 receives the MAC/IP Advertisement and imports 148 it to the L3 EVI, PE2 installs an ARP entry to the VRF interface 149 whose subnet matches the IP Address from the MAC/IP Advertisement. 150 Such ARP entry is called remote synched ARP Entry in this document. 152 Note that the PEs follow [I-D.sajassi-bess-evpn-ip-aliasing] to 153 achieve the ESI load balance except for the constructing of MAC/IP 154 Advertisement Route and IP-EAD/EVI route. 156 When PE3 load balance the traffic towards the multihomed Ethernet 157 Segment, both PE1 and PE2 would have been prepared with corresponding 158 ARP entry yet because of the ARP synching procedures. 160 It is important to explain that typically there may be both IRB 161 interface and VRF interface in an IP-VRF instance, which is called as 162 the "VRF interface in EVPN IRB" use-case in this document. But each 163 IRB/VRF interface is independent to each other in EVPN control plane. 164 So the use-case here is constrained to a pure L3 EVPN schema, Because 165 it is enough to describe all the control-plane updates for both the 166 pure L3 EVPN use-case and the "VRF interface in EVPN IRB" use-case. 168 In current EVPN control-plane for "VRF interface in EVPN IRB" use- 169 case, the VRF interface is considered as "external link" and it just 170 inter-operates with the EVPN control-plane. But in this document it 171 is assumed to be better if the EVPN control-plane directly applied to 172 the VRF interface. 174 2.1. Constructing MAC/IP Advertisement Route 176 This draft introduces a new usage/construction of MAC/IP 177 Advertisement route to enable Aliasing for IP addresses in pure L3 178 EVPN use-cases. The usage/construction of this route remains similar 179 to that described in RFC 7432 with a few notable exceptions as below. 181 * The Route-Distinguisher should be set to the corresponding L3VPN 182 context. 184 * The Ethernet Tag should be set to 0. 186 * The MAC/IP Advertisement SHOULD carry one or more IP VRF Route- 187 Target (RT) attributes. 189 * The ESI SHOULD be set to the ESI of the VRF interface from which 190 the ARP entry is learned. 192 Note that the ESI is not used to install remote synched ARP entries 193 to corresponding VRF interfaces on PE1/PE2. It is only used to load 194 balance traffic on PE3. 196 * The MPLS Label1 should be set to implicit-null in MPLS/SRv6 197 encapsulation. For VXLAN encapsulation, the MPLS label1 should be 198 set to 0 instead. Note that no MAC- VRF can be found here. 200 * The MPLS Label2 should be set to the local label of the IP-VRF in 201 MPLS or VXLAN EVPN. But it should be set to implicit-null in SRv6 202 EVPN. 204 Note that the label may be VNI label or MPLS label. 206 Note that in SRv6 EVPN an SRv6 L3 Service TLV MAY also be advertised 207 along with the route following [I-D.dawra-bess-srv6-services]. But 208 SRv6 L2 Service TLV won't be advertiseed along with the route. 209 Because that no MAC-VRF exists in the use case. 211 * The RMAC Extended Community attribute SHOULD be carried in VXLAN 212 EVPN. 214 2.2. Constructing EAD/IP-VRF Route 216 Note that the MAC/IP Advertisement is used for two reasons. It is 217 used between PE1 and PE2 to synch the ARP entries to each other. It 218 is used between PE1/PE2 and PE3 to achieve the load balance to ES 219 adjacent PEs. 221 The usage/construction of this route is similar to the IP-EAD/EVI 222 route described in [I-D.sajassi-bess-evpn-ip-aliasing] with a few 223 notable exceptions as below. 225 * The MPLS Label should be set to the local label of the IP-VRF in 226 MPLS EVPN or VXLAN EVPN. But it should be set to implicit-null in 227 SRv6 EVPN. 229 Note that in SRv6 EVPN an L3 Service SID MAY also be advertised along 230 with the route following [I-D.dawra-bess-srv6-services]. 232 Such Ethernet Auto-Discovery route is called Ethernet Auto-Discvoery 233 route per IP-VRF which is abbreviated as EAD/IP-VRF in this document. 235 2.3. Constructing EAD/ES Route 237 The usage/construction of this route remains similar to that 238 described in section 3.1.1. of [I-D.sajassi-bess-evpn-ip-aliasing] 239 with a few notable exceptions as explained as below. 241 There may be no MAC-VRF RTs in the EAD/ES Route. 243 3. Fast Convergence for Routed Traffic 245 The procedures for Fast Convergence do not change from 246 [I-D.sajassi-bess-evpn-ip-aliasing] except for a few notable 247 exceptions as explained as below. 249 The local ARP entries and remote synced ARP entries is installed/ 250 learned on a VRF interface rather than an IRB interface. 252 There is no MAC entry. 254 4. Determining Reach-ability to Unicast IP Addresses 256 The procedures for local/remote host learning and MAC/IP 257 Advertisement route constructing are described above. The procedures 258 for Route Resolution do not change from [I-D.sajassi-bess-evpn-ip- 259 aliasing]. 261 5. Forwarding Unicast Packets 263 Because of the nature of the MPLS label or SRv6 SID for IP-VRF 264 instance, when these EAD/IP-VRF routes are referred in IP-VRF routing 265 and forwarding procedures, the inner ethernet headers are absent on 266 the corresponding packets transported following these EAD/IP-VRF 267 routes. 269 Note that in [I-D.sajassi-bess-evpn-ip-aliasing] the inner ethernet 270 header need to be included in the packets which are sent from IP-VRF 271 following IP-EAD/EVI routes, becuase that the MPLS label of such IP- 272 EAD/EVI route is for MAC-VRF, not for IP-VRF. and the inner 273 destination MAC of these packets is following the "Router's MAC" 274 extended community of MAC/IP advertisement routes with non-zero ESI. 275 But in many use cases, the RMAC is not the same as the IRB 276 interface's own MAC and the RMAC is not the same among different PEs. 277 For example, the MAC address of the two IRB interfaces with anycast 278 GW-IP address will be the same, but these two IRB interfaces lies on 279 two different GW node and their "Router's MAC" is typically not the 280 same. In these use cases, it is recommanded to use EAD/IP-VRF route 281 instead, even if there is indeed a MAC-VRF instance. 283 Note that in EVPN IRB use cases, the EAD/IP-VRF route is more 284 accordant with the symmetric IRB concept in the sense of data-plane 285 behavior for unicast packets than the IP-EAD/EVI route of 286 [I-D.sajassi-bess-evpn-ip-aliasing]. 288 Note that from the viewpoint of the route receiver It is impossible 289 to distinguish the EAD/IP-VRF route from the IP-EAD/EVI route. So 290 the receiver has to configure how to interprete the remote EAD/EVI 291 route. If it is interpreted as EAD/IP-VRF route, the corresponding 292 transported unicast packets will not be inserted with an ethernet 293 header. But if it is interpreted as IP-EAD/EVI route, they will. 294 Note that we will rely on such configuration only in MPLS/SRv6 EVPN, 295 it is not needed in VXLAN EVPN. 297 6. Use RT-5 Route with ESI to Reduce Route Advertisement 299 Given that PE1/PE2 can receive remote synced ARP entries from each 300 other by RT-2 route following section 2.1. So it is not necessary 301 for PE1/PE2 to advertise per-host IP prefixes by RT-2 routes. It is 302 recommended that PE1/PE2 advertise an RT-5 route per subnet to PE3 303 instead. The ESI of these RT-5 routes can be set to the ESI of the 304 corresponding VRF interface. If the VRF interface fails, these 305 subnets will achieve more faster convergency on PE3 by the withdraw 306 of the corresponding EAD/IP-VRF route. 308 7. Load Balancing of Unicast Packets 310 It is the same as [I-D.sajassi-bess-evpn-ip-aliasing]. 312 8. Security Considerations 314 This document does not introduce any new security considerations 315 other than already discussed in [RFC7432] and [RFC8365]. 317 9. IANA Considerations 319 There is no IANA consideration. 321 10. Normative References 323 [I-D.dawra-bess-srv6-services] 324 Dawra, G., Filsfils, C., Brissette, P., Agrawal, S., 325 Leddy, J., daniel.voyer@bell.ca, d., 326 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 327 Decraene, B., Matsushima, S., Zhuang, S., and J. Rabadan, 328 "SRv6 BGP based Overlay services", draft-dawra-bess- 329 srv6-services-02 (work in progress), July 2019. 331 [I-D.ietf-bess-evpn-prefix-advertisement] 332 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 333 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 334 bess-evpn-prefix-advertisement-11 (work in progress), May 335 2018. 337 [I-D.sajassi-bess-evpn-ip-aliasing] 338 Sajassi, A., Badoni, G., Warade, P., and S. Pasupula, "L3 339 Aliasing and Mass Withdrawal Support for EVPN", draft- 340 sajassi-bess-evpn-ip-aliasing-00 (work in progress), July 341 2017. 343 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 344 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 345 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 346 2015, . 348 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 349 Uttaro, J., and W. Henderickx, "A Network Virtualization 350 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 351 DOI 10.17487/RFC8365, March 2018, 352 . 354 Authors' Addresses 356 Yubao(Bob) Wang 357 ZTE Corporation 358 No. 50 Software Ave, Yuhuatai Distinct 359 Nanjing 360 China 362 Email: yubao.wang2008@hotmail.com 364 Zheng(Sandy) Zhang 365 ZTE Corporation 366 No. 50 Software Ave, Yuhuatai Distinct 367 Nanjing 368 China 370 Email: zzhang_ietf@hotmail.com