idnits 2.17.1 draft-wang-bess-evpn-arp-nd-synch-without-irb-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 ([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 179: '...IP Advertisement SHOULD carry one or m...' RFC 2119 keyword, line 182: '... * The ESI SHOULD be set to the ESI ...' RFC 2119 keyword, line 198: '...n L3 Service SID MAY also be advertise...' RFC 2119 keyword, line 201: '...munity attribute SHOULD be carried in ...' RFC 2119 keyword, line 219: '...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 (April 25, 2019) is 1827 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) == Outdated reference: A later version (-02) exists of draft-dawra-bess-srv6-services-00 == 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: October 27, 2019 April 25, 2019 7 ARP/ND Synching And IP Aliasing without IRB 8 draft-wang-bess-evpn-arp-nd-synch-without-irb-00 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 October 27, 2019. 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 IP-EAD/EVI Route . . . . . . . . . . . . . . 5 56 2.3. Constructing EAD/ES Route . . . . . . . . . . . . . . . . 5 57 3. Fast Convergence for Routed Traffic . . . . . . . . . . . . . 5 58 4. Determining Reach-ability to Unicast IP Addresses . . . . . . 6 59 5. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . 6 60 6. Load Balancing of Unicast Packets . . . . . . . . . . . . . . 6 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 [I-D.sajassi-bess-evpn-ip-aliasing] proposes an extension to 69 [RFC7432] to do aliasing for Layer 3 routes that is needed for 70 symmetric IRB to build a complete IP ECMP. But typically there may 71 be both IRB interfaces(to do EVPN IRB per-MAC-VRF basis) and VRF- 72 interfaces in the same IP-VRF instance. It is necessary to apply the 73 EVPN control-plane to the VRF-interfaces in order to support both 74 such situations and the pure L3 EVPN use case where no IRB interfaces 75 will be found in the IP-VRF instances. 77 +---------+ 78 +-------------+ | | 79 | | | | 80 /| PE1 |----| | +-------------+ 81 / | | | MPLS/ | | | 82 LAG / +-------------+ | VxLAN/ | | PE3 |---H3 83 H1---SW1===== | NVGRE/ | | | 84 / \ +-------------+ | SRv6 |---| | 85 H2 \ | | | | +-------------+ 86 \| PE2 |----| | 87 | | | | 88 +-------------+ | | 89 | | 90 | | 91 +---------+ 93 Figure 1: ARP/ND Synchronizing and IP Aliasing without IRB 95 Consider a pair of multi-homed PEs PE1 and PE2. Let there be two 96 hosts H1 and H2 attached to them via a L2 switch SW1. Consider 97 another PE PE3 and a host H3 attached to it. The H1 and H2 represent 98 subnet SN1 and the H3 represents subnet SN2. 100 Note that it is different from [I-D.sajassi-bess-evpn-ip-aliasing] in 101 the following aspects: There is no MAC-VRF or IRB interface on 102 PE1/PE2/PE3. And it is the IP-VRFs that are called as EVPN instance 103 instead. Such EVPN instance can be called pure L3 EVPN instance or 104 L3 EVI for short. The anycast gateway of H1/H2 is configured on a 105 sub-interface on PE1/PE2. 107 Note that the communication between H1 and H2 won't pass through any 108 of the multi-homed PEs. So it is not necessary for PE1/PE2 keeping a 109 Broadcast domain and its IRB for SN1. 111 Note that the SW1 multi-homing PE1 and PE2 via a LAG interface which 112 maybe load-balance traffic to the PEs. 114 This draft proposes an extension to do ARP/ND synchronizing and IP 115 aliasing for Layer 3 routes that is needed for L3 EVI to build a 116 complete IP ECMP. 118 1.1. Terminology 120 Most of the terminology used in this documents comes from [RFC7432] 121 and [I-D.sajassi-bess-evpn-ip-aliasing] except for the following: 123 VRF Interface: A interface that connects to a CE for an IP-VRF but is 124 not an IRB interface. 126 L3 EVI: An EVPN instance spanning the Provider Edge (PE) devices 127 participating in that EVPN which contains VRF Interfaces and maybe 128 contains IRB interfaces. 130 2. ARP/ND Synching and IP Aliasing 132 Host IP and MAC routes are learnt by PEs on the access side via a 133 control plane protocol like ARP. In case where a CE is multihomed to 134 multiple PE nodes using a LAG and is running in All-Active Redundancy 135 Mode, the Host IP will be learnt and advertised in the MAC/IP 136 Advertisement only by the PE that receives the ARP packet. The MAC/ 137 IP Advertisement with non-zero ESI will be received by both PE2 and 138 PE3. 140 As a result, after PE2 receives the MAC/IP Advertisement and imports 141 it to the L3 EVI, PE2 installs an ARP entry to the VRF interface 142 whose subnet matches the IP Address from the MAC/IP Advertisement. 143 Such ARP entry is called remote synched ARP Entry in this document. 145 Note that the PEs follow [I-D.sajassi-bess-evpn-ip-aliasing] to 146 achieve the ESI load balance except for the constructing of MAC/IP 147 Advertisement Route and IP-EAD/EVI route. 149 When PE3 load balance the traffic towards the multihomed Ethernet 150 Segment, both PE1 and PE2 would have been prepared with corresponding 151 ARP entry yet because of the ARP synching procedures. 153 It is important to explain that typically there may be both IRB 154 interface and VRF interface in an IP-VRF instance, which is called as 155 the "VRF interface in EVPN IRB" use-case in this document. But each 156 IRB/VRF interface is independent to each other in EVPN control plane. 157 So the use-case here is constrained to a pure L3 EVPN schema, Because 158 it is enough to describe all the control-plane updates for both the 159 pure L3 EVPN use-case and the "VRF interface in EVPN IRB" use-case. 161 In current EVPN control-plane for "VRF interface in EVPN IRB" use- 162 case, the VRF interface is considered as "external link" and it just 163 inter-operates with the EVPN control-plane. But in this document it 164 is assumed to be better if the EVPN control-plane directly applied to 165 the VRF interface. 167 2.1. Constructing MAC/IP Advertisement Route 169 This draft introduces a new usage/construction of MAC/IP 170 Advertisement route to enable Aliasing for IP addresses in pure L3 171 EVPN use-cases. The usage/construction of this route remains similar 172 to that described in RFC 7432 with a few notable exceptions as below. 174 * The Route-Distinguisher should be set to the corresponding L3VPN 175 context. 177 * The Ethernet Tag should be set to 0. 179 * The MAC/IP Advertisement SHOULD carry one or more IP VRF Route- 180 Target (RT) attributes. 182 * The ESI SHOULD be set to the ESI of the VRF interface from which 183 the ARP entry is learned. 185 Note that the ESI is not used to install remote synched ARP entries 186 to corresponding VRF interfaces on PE1/PE2. It is only used to load 187 balance traffic on PE3. 189 * The MPLS Label1 should be set to implicit-null. Note that no MAC- 190 VRF can be found here. 192 * The MPLS Label2 should be set to the local label of the IP-VRF in 193 MPLS or VXLAN EVPN. But it should be set to implicit-null in SRv6 194 EVPN. 196 Note that the label may be VNI label or MPLS label. 198 Note that in SRv6 EVPN an L3 Service SID MAY also be advertised along 199 with the route following [I-D.dawra-bess-srv6-services]. 201 * The RMAC Extended Community attribute SHOULD be carried in VXLAN 202 EVPN. 204 2.2. Constructing IP-EAD/EVI Route 206 Note that the MAC/IP Advertisement is used for two reasons. It is 207 used between PE1 and PE2 to synch the ARP entries to each other. It 208 is used between PE1/PE2 and PE3 to achieve the load balance to ES 209 adjacent PEs. 211 The usage/construction of this route remains similar to that 212 described in [I-D.sajassi-bess-evpn-ip-aliasing] with a few notable 213 exceptions as below. 215 * The MPLS Label should be set to the local label of the IP-VRF in 216 MPLS EVPN or VXLAN EVPN. But it should be set to implicit-null in 217 SRv6 EVPN. 219 Note that in SRv6 EVPN an L3 Service SID MAY also be advertised along 220 with the route following [I-D.dawra-bess-srv6-services]. 222 2.3. Constructing EAD/ES Route 224 The usage/construction of this route remains similar to that 225 described in section 3.1.1. of [I-D.sajassi-bess-evpn-ip-aliasing] 226 with a few notable exceptions as explained as below. 228 There may be no MAC-VRF RTs in the EAD/ES Route. 230 3. Fast Convergence for Routed Traffic 232 The procedures for Fast Convergence do not change from 233 [I-D.sajassi-bess-evpn-ip-aliasing] except for a few notable 234 exceptions as explained as below. 236 The local ARP entries and remote synced ARP entries is installed/ 237 learned on a VRF interface rather than an IRB interface. 239 There is no MAC entry. 241 4. Determining Reach-ability to Unicast IP Addresses 243 The procedures for local/remote host learning and MAC/IP 244 Advertisement route constructing are described above. The procedures 245 for Route Resolution do not change from 246 [I-D.sajassi-bess-evpn-ip-aliasing]. 248 5. Forwarding Unicast Packets 250 It is the same as [I-D.sajassi-bess-evpn-ip-aliasing]. 252 6. Load Balancing of Unicast Packets 254 It is the same as [I-D.sajassi-bess-evpn-ip-aliasing]. 256 7. Security Considerations 258 This document does not introduce any new security considerations 259 other than already discussed in [RFC7432] and [RFC8365]. 261 8. IANA Considerations 263 There is no IANA consideration. 265 9. Normative References 267 [I-D.dawra-bess-srv6-services] 268 Dawra, G., Filsfils, C., Dukes, D., Brissette, P., 269 Sethuram, S., Camarillo, P., Leddy, J., 270 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 271 Steinberg, D., Raszuk, R., Decraene, B., Matsushima, S., 272 and S. Zhuang, "SRv6 BGP based Overlay services", draft- 273 dawra-bess-srv6-services-00 (work in progress), March 274 2019. 276 [I-D.sajassi-bess-evpn-ip-aliasing] 277 Sajassi, A., Badoni, G., Warade, P., and S. Pasupula, "L3 278 Aliasing and Mass Withdrawal Support for EVPN", draft- 279 sajassi-bess-evpn-ip-aliasing-00 (work in progress), July 280 2017. 282 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 283 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 284 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 285 2015, . 287 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 288 Uttaro, J., and W. Henderickx, "A Network Virtualization 289 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 290 DOI 10.17487/RFC8365, March 2018, 291 . 293 Authors' Addresses 295 Yubao(Bob) Wang 296 ZTE Corporation 297 No. 50 Software Ave, Yuhuatai Distinct 298 Nanjing 299 China 301 Email: yubao.wang2008@hotmail.com 303 Zheng(Sandy) Zhang 304 ZTE Corporation 305 No. 50 Software Ave, Yuhuatai Distinct 306 Nanjing 307 China 309 Email: zzhang_ietf@hotmail.com