idnits 2.17.1 draft-rbickhart-evpn-ip-mac-proxy-adv-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 23, 2020) is 1553 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 (-09) exists of draft-ietf-bess-evpn-na-flags-04 == Outdated reference: A later version (-16) exists of draft-ietf-bess-evpn-proxy-arp-nd-08 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup R. Bickhart 3 Internet-Draft Twitch 4 Intended status: Standards Track W. Lin 5 Expires: July 26, 2020 J. Drake 6 Juniper Networks 7 J. Rabadan 8 Nokia 9 A. Lo 10 Arista Networks 11 January 23, 2020 13 Proxy IP->MAC Advertisement in EVPNs 14 draft-rbickhart-evpn-ip-mac-proxy-adv-01 16 Abstract 18 This document specifies procedures for EVPN PEs connected to a common 19 multihomed site to generate proxy EVPN type 2 IP->MAC advertisements 20 on behalf of other PEs to facilitate preservation of ARP/ND state 21 across link or node failures. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 26, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. IP->MAC Proxy Advertisements . . . . . . . . . . . . . . . . 3 60 3.1. Interoperation with Legacy PEs . . . . . . . . . . . . . 5 61 3.2. Single-Active Multihoming Considerations . . . . . . . . 5 62 3.3. MAC Route Attribute Considerations . . . . . . . . . . . 5 63 3.4. Symmetric IRB Considerations . . . . . . . . . . . . . . 6 64 4. EVPN ARP/ND Extended Community . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. Operational Considerations . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Conventions and Terminology 73 This document assumes familiarity with the terminology used in EVPN 74 [RFC7432]. A few key terms used in this document are defined below: 76 CE: Customer edge device. 78 PE: Provider edge device. 80 IP->MAC: An IP address associated with a MAC address. 82 ARP: Address Resolution Protocol. 84 ND: Neighbor Discovery Protocol. 86 DF: Designated Forwarder. 88 R-bit: Router Flag in NA messages, as per ND for IPv6 [RFC4861]. 90 O-bit: Override Flag in NA messages, as per ND for IPv6 [RFC4861]. 92 2. Introduction 94 EVPN [RFC7432] allows for the distribution of IP->MAC bindings of 95 connected hosts learned through IPv4 ARP and IPv6 neighbor discovery 96 (ND) using type 2 MAC/IP advertisement routes. When end hosts are 97 connected to a multihomed site of an EVPN running in all-active mode, 98 depending on the learning mechanisms of the multihoming PEs and the 99 load balancing mechanisms implemented by the CE devices multihomed to 100 the EVPN PEs, local learning of an IP->MAC may be limited to a subset 101 of the total number of multihoming PEs, possibly only a single PE 102 device. In the steady state, the IP->MAC originally learned locally 103 on one or more of the set of multihoming PEs is synchronized to all 104 remaining PEs attached to the same multihoming site via the EVPN 105 control plane. Once synchronized, the IP->MAC is available on each 106 multihoming PE as well as other remote PEs not connected to the 107 multihomed site for use in forwarding traffic or suppressing ARP or 108 ND messaging in the EVPN. 110 In the event of the complete failure of a multihoming PE or the 111 failure of a multihoming PE's link to the multihomed site, any 112 IP->MAC locally learned on that PE or locally attached link will be 113 invalidated and will be withdrawn from the EVPN control plane. If 114 the source of the failure was the only origin of any particular 115 IP->MAC, that IP->MAC will completely disappear from the EVPN until 116 such time that one of the remaining multihoming PEs is able to 117 relearn the IP->MAC that was lost. Traffic forwarding or other EVPN 118 features like ARP/ND suppression may fail during the intermediate 119 period between the loss of the IP->MAC from the original local 120 learning PE and later learning and distribution of the IP->MAC from a 121 new local learning PE. 123 This document specifies procedures to preserve IP->MAC state across 124 the remaining multihoming PEs in the EVPN to bridge the gap between 125 the initial failure and the subsequent relearning of the IP->MAC on 126 one of the remaining multihoming PEs. 128 3. IP->MAC Proxy Advertisements 130 Preserving IP->MAC state in the EVPN until relearning and 131 distribution of the new IP->MAC state to all PEs is completed can be 132 accomplished by using IP->MAC proxy advertisements. When an IP->MAC 133 for a host connected to a multihomed site is locally learned by a PE, 134 the PE will advertise the IP->MAC via an EVPN MAC/IP route as usual. 135 When other PEs learn that IP->MAC from the control plane upon 136 reception of the MAC/IP route, they will install the ARP/ND state 137 derived from the received IP->MAC for local use as usual. 138 Additionally, if the receiving PE is locally connected to the same 139 multihomed ethernet segment where the received IP->MAC originated and 140 the IP->MAC was not previously locally learned and advertised, the 141 receiving PE will inject its own EVPN MAC/IP route carrying the same 142 IP->MAC (and with the same ESI) into the control plane and mark that 143 injected route with a special proxy IP->MAC indication. Assuming 144 that all PEs attached to the multihomed site support this proxy 145 advertisement functionality, the result is that each PE attached to 146 the site will originate the given IP->MAC using an EVPN MAC/IP route, 147 some of the route advertisements possibly carrying the proxy 148 indication and at least one route advertisement not marked with the 149 proxy indication. 151 A subsequent PE failure, link failure, or other event triggering the 152 loss of all non-proxy IP->MAC state on a multihoming PE will cause 153 that PE to start an aging timer for the proxy IP->MAC the PE had 154 previously advertised. The aging timer should be initialized to the 155 same age-time as the system default for ARP/ND aging, but an 156 implementation may allow the initial age-time used for proxy a 157 IP->MAC to be set administratively. While the aging timer is 158 running, the multihoming PE will take no other actions and will 159 continue using the proxy IP->MAC state for local forwarding and ARP/ 160 ND purposes and will continue to advertise the IP->MAC in the control 161 plane with the proxy indication set. Remote PEs not connected to the 162 multihomed site will ignore the proxy indication completely, and will 163 be unaware of the difference between proxy and non-proxy IP->MAC 164 advertisements. In this state, the EVPN will continue working as 165 before the failure, with the exception of the failed link or PE being 166 removed from the forwarding path. 168 In the event that one of the remaining multihoming PEs now learns the 169 IP->MAC locally, it will restart the aging timer for the IP->MAC with 170 the default ARP/ND age-time and remove the proxy indication from the 171 EVPN MAC/IP route for the IP->MAC previously advertised in the 172 control plane. When any other multihoming PE observes the removal of 173 the proxy indication from at least one of the sources advertising the 174 IP->MAC, that PE will stop the aging timer for the locally advertised 175 proxy IP->MAC and continue advertising the IP->MAC with the proxy 176 indication set as before. 178 In the event that a multihoming PE fails to learn the IP->MAC locally 179 before the aging timer for the proxy IP->MAC expires, that PE will 180 withdraw the EVPN MAC/IP route for proxy IP->MAC that it had 181 advertised previously. In this way, if all multihoming PEs fail to 182 learn the IP->MAC locally within the age-time, the proxy IP->MAC 183 advertisements will expire on every PE and will be withdrawn, 184 completely removing the IP->MAC from the EVPN. 186 In the case that a non-proxy IP->MAC is withdrawn from the EVPN 187 because the original dynamically learned ARP/ND entry ages out due to 188 end host inactivity or shutdown rather than a PE node or link 189 failure, PEs which advertised a proxy IP->MAC will still follow the 190 same procedures as above and retain their proxy IP->MAC 191 advertisements until the age-time has passed. Implementations may 192 allow the proxy IP->MAC age-time to be administratively specified 193 separately from the regular system ARP/ND age-time to tune how fast 194 stale proxy IP->MAC advertisements are cleared from the EVPN. 195 Additionally, a PE may optionally use a mechanism like send-refresh 196 [I-D.ietf-bess-evpn-proxy-arp-nd] to probe the liveness of the 197 IP->MAC and withdraw the proxy IP->MAC from the control plane before 198 the age-time if the PE determines that the IP->MAC is no longer 199 active. 201 3.1. Interoperation with Legacy PEs 203 A heterogenous mix of new PEs supporting proxy IP->MAC advertisement 204 and legacy PEs not supporting proxy IP->MAC advertisement is 205 supported in the event of incremental configuration of the feature or 206 incremental upgrades of PEs attached to the same ethernet segment. 207 Although legacy PE devices will continue to operate with the 208 traditional mechanisms and advertise only locally learned IP->MAC 209 entries, they can make use of any remotely learned proxy IP->MAC 210 advertised by other PEs supporting proxy advertisement. 212 3.2. Single-Active Multihoming Considerations 214 Proxy IP->MAC advertisement is not applicable to ethernet segments 215 configured for single-active multihoming because MAC advertisements 216 are the indication of which multihoming PE is the DF for remote PEs 217 not directly connected ethernet segment. Advertisement of a proxy 218 IP->MAC by a non-DF multihoming PE will prevent remote PEs not 219 directly attached to the ethernet segment from determining the 220 correct DF. 222 3.3. MAC Route Attribute Considerations 224 When a PE advertises a proxy IP->MAC that was originally learned from 225 the control plane with a MAC mobility extended community attached 226 with a nonzero sequence number, the PE should advertise the new proxy 227 IP->MAC with the same sequence number as originally received. The 228 presence or lack of a proxy indication for a received IP->MAC 229 advertisement should not be used in active MAC determination for MAC 230 mobility purposes. 232 When a PE advertises a proxy IP->MAC for an IPv6 address learned from 233 the control plane that has the 'R' or 'O' bits set in the EVPN ND 234 extended community, the new proxy IP->MAC should carry an EVPN ND 235 extended community with the same 'R' and 'O' bits as originally 236 received. 238 3.4. Symmetric IRB Considerations 240 When a PE advertises a proxy IP->MAC, it may check the configuration 241 of the corresponding local IRB interface to determine whether IRB is 242 operating in symmetric or asymmetric mode. In the case of symmetric 243 IRB, the advertising PE may set the MPLS Label2 field of the type 2 244 MAC/IP advertisement route to either an MPLS label or a VNI 245 corresponding to the IP->MAC's IP-VRF on the PE. When the MPLS 246 Label2 field is populated with a VNI, the PE should additionally 247 include the Router's MAC Extended Community carrying the MAC address 248 of the PE originating the IP->MAC proxy advertisement. 250 As described in section 3 above, all hosts connected to an ES are 251 advertised by at least one PE without the proxy indication set and 252 also by any number of additional PEs with the proxy indication set. 253 A remote PE can then import the proxy and non-proxy IP->MAC 254 advertisements into its IP-VRF and use the MPLS label or VNI carried 255 in the MPLS Label2 field of the IP->MAC advertisements to route IP 256 traffic to hosts connected to the ES. 258 This approach does not utilize the layer 2 multihoming aliasing 259 mechanism which is provided by the ESI carried in the type 2 MAC/IP 260 advertisement routes. Instead, IP route programming is based purely 261 on normal IP multipath procedures using the routes imported to the 262 IP-VRFs on remote PEs. 264 4. EVPN ARP/ND Extended Community 266 EVPN already provides an extended community to signal additional 267 state relevant to IPv6 ND (the override and router bits). Because 268 the proxy indication described in this document is equally applicable 269 to both ARP and ND, we propose renaming the EVPN Neighbor Discovery 270 (ND) Extended Community (type 0x08) to EVPN ARP/ND Extended Community 271 and allocating an additional bit from the flags field of the 272 community to signal the proxy advertisement state. 274 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type=0x06 | Sub-Type=0x08 |Reserved |P|O|R| Reserved=0 | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Reserved=0 | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 The following bits in the flags field in the third octet of the 282 extended community are defined. The remaining bits must be set to 283 zero when sending and must be ignored when receiving this community. 285 +--------+----------------------------------------------------------+ 286 | Bit | Meaning | 287 | Name | | 288 +--------+----------------------------------------------------------+ 289 | O,R | Defined in IPv6 Neighbor Advertisement Flags in EVPN | 290 | | [I-D.ietf-bess-evpn-na-flags] | 291 | P | Proxy IP->MAC advertisement defined in this draft | 292 +--------+----------------------------------------------------------+ 294 EVPN ARP/ND Extended Community Flags 296 5. IANA Considerations 298 This document requests the value of 0x04 of the EVPN ARP/ND extended 299 community flags field to be assigned to the proxy IP->MAC 300 advertisement (P) bit. 302 6. Operational Considerations 304 Depending on the number of multihoming PEs and MAC/IP scaling of an 305 EVPN, proxy advertisement of IP->MAC entries by other PEs in addition 306 to the devices initially learning IP->MAC entries locally in the data 307 plane could cause scalability concerns for operators. Proxy 308 advertisements would increase the total number of EVPN routes 309 maintained in the route tables of PEs, as well as increase the time 310 required for PEs to download all remotely learned EVPN routes. 311 Protocol implementations should provide administrative controls for 312 operators to limit proxy advertisement functionality to situations 313 where the benefits are required and the scale overhead is acceptable. 315 7. Security Considerations 317 This draft does not introduce any new security considerations to 318 EVPN. 320 8. Normative References 322 [I-D.ietf-bess-evpn-na-flags] 323 Rabadan, J., Sathappan, S., Nagaraj, K., and W. Lin, 324 "Propagation of ARP/ND Flags in EVPN", draft-ietf-bess- 325 evpn-na-flags-04 (work in progress), July 2019. 327 [I-D.ietf-bess-evpn-proxy-arp-nd] 328 Rabadan, J., Sathappan, S., Nagaraj, K., Hankins, G., and 329 T. King, "Operational Aspects of Proxy-ARP/ND in EVPN 330 Networks", draft-ietf-bess-evpn-proxy-arp-nd-08 (work in 331 progress), July 2019. 333 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 334 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 335 DOI 10.17487/RFC4861, September 2007, 336 . 338 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 339 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 340 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 341 2015, . 343 Authors' Addresses 345 Ryan Bickhart 346 Twitch 348 Email: rbickhar@twitch.tv 350 Wen Lin 351 Juniper Networks 353 Email: wlin@juniper.net 355 John Drake 356 Juniper Networks 358 Email: jdrake@juniper.net 360 Jorge Rabadan 361 Nokia 363 Email: jorge.rabadan@nokia.com 365 Alton Lo 366 Arista Networks 368 Email: altonlo@arista.com