| Internet-Draft | Proxy MAC-IP Advertisement in EVPNs | October 2024 |
| Bickhart, et al. | Expires 21 April 2025 | [Page] |
This document specifies procedures for EVPN PEs connected to a common multihomed site to generate proxy EVPN MAC-IP advertisements on behalf of other PEs to facilitate preservation of ARP/ND state across link or node failures.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document assumes familiarity with the terminology used in EVPN [RFC7432]. A few key terms used in this document are defined below:¶
CE: Customer edge device.¶
PE: Provider edge device.¶
MAC-IP: An IP address associated with a MAC address.¶
ARP: Address Resolution Protocol.¶
ND: Neighbor Discovery Protocol.¶
DF: Designated Forwarder.¶
R-bit: Router Flag in NA messages, as per ND for IPv6 [RFC4861].¶
O-bit: Override Flag in NA messages, as per ND for IPv6 [RFC4861].¶
EVPN [RFC7432] allows for the distribution of MAC-IP bindings of connected hosts learned through IPv4 ARP and IPv6 neighbor discovery (ND) using EVPN MAC/IP advertisement routes. When end hosts are connected to a multihomed site running EVPN in all-active mode, depending on the learning mechanisms of the multihoming Provider Edge (PE) devices and the load balancing scheme implemented by the connected end hosts, local learning of a MAC-IP may be limited to a subset of the total number of multihoming PEs, possibly only a single PE device. In the steady state, the MAC-IP originally learned locally on one or more of the set of multihoming PEs is synchronized to all remaining PEs attached to the same multihoming site via the EVPN control plane. Once synchronized, the MAC-IP is available on each multihoming PE as well as other remote PEs not connected to the multihomed site for use in forwarding traffic or suppressing ARP or ND messaging in the EVPN.¶
When a multihoming PE or its link to the Customer Edge (CE) device breaks down, any MAC-IP locally learned on that link by that PE will be invalidated and will be withdrawn from the EVPN control plane. If the PE was the only one that learned of any particular MAC-IP locally, that MAC-IP will entirely removed from both the EVPN control and forwarding plane until another PE can learn the MAC-IP again. Traffic forwarding or other EVPN features like ARP/ND suppression may fail during the intermediate period between the loss of the MAC-IP from the original local learning PE and later learning and distribution of the MAC-IP from a new local learning PE.¶
This document specifies procedures to preserve MAC-IP state across the remaining multihoming PEs in the EVPN to bridge the gap between the initial failure and the subsequent relearning of the MAC-IP on one of the remaining multihoming PEs.¶
Preserving MAC-IP state in the EVPN until relearning and distribution of the new MAC-IP state to all PEs is completed can be accomplished by using MAC-IP proxy advertisements. When an MAC-IP for a host connected to a multihomed site is locally learned by a PE, the PE will advertise the MAC-IP via an EVPN MAC/IP route as usual. When other PEs learn that MAC-IP from the control plane upon reception of the MAC/IP route, they will install the ARP/ND state derived from the received MAC-IP for local use as usual. Additionally, if the receiving PE is locally connected to the same multihomed ethernet segment where the received MAC-IP originated and the MAC-IP was not previously locally learned and advertised, the receiving PE will inject its own EVPN MAC/IP route carrying the same MAC-IP (and with the same ESI) into the control plane and mark that injected route with a special proxy MAC-IP indication. Assuming that all PEs attached to the multihomed site support this proxy advertisement functionality, the result is that each PE attached to the site will originate the given MAC-IP using an EVPN MAC/IP route, some of the route advertisements possibly carrying the proxy indication and at least one route advertisement not marked with the proxy indication.¶
A subsequent PE failure, link failure, or other event triggering the loss of all non-proxy MAC-IP state on a multihoming PE will cause that PE to start an aging timer for the proxy MAC-IP the PE had previously advertised. The aging timer should be initialized to the same age-time as the system default for ARP/ND aging, but an implementation may allow the initial age-time used for proxy a MAC-IP to be set administratively. While the aging timer is running, the multihoming PE will take no other actions and will continue using the proxy MAC-IP state for local forwarding and ARP/ND purposes and will continue to advertise the MAC-IP in the control plane with the proxy indication set. Remote PEs not connected to the multihomed site will ignore the proxy indication completely, and will be unaware of the difference between proxy and non-proxy MAC-IP advertisements. In this state, the EVPN will continue working as before the failure, with the exception of the failed link or PE being removed from the forwarding path.¶
In the event that one of the remaining multihoming PEs now learns the MAC-IP locally, it will restart the aging timer for the MAC-IP with the default ARP/ND age-time and remove the proxy indication from the EVPN MAC/IP route for the MAC-IP previously advertised in the control plane. When any other multihoming PE observes the removal of the proxy indication from at least one of the sources advertising the MAC-IP, that PE will stop the aging timer for the locally advertised proxy MAC-IP and continue advertising the MAC-IP with the proxy indication set as before. A PE may opt to accelerate the MAC-IP learning process by using a mechanism like send-refresh, as outlined in Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Network [RFC9161], before the aging timer for proxy MAC-IP entry expires.¶
If a multihoming PE does not manage to learn the MAC-IP locally before the aging timer for the proxy MAC-IP expires, that PE will withdraw the EVPN MAC/IP route for proxy MAC-IP that it had advertised previously. In this way, if all multihoming PEs fail to learn the MAC-IP locally within the age-time, the proxy MAC-IP advertisements will expire on every PE and will be withdrawn, completely removing the MAC-IP from both the EVPN control and forwarding plane.¶
In the case that a non-proxy MAC-IP is withdrawn from the EVPN because the original dynamically learned ARP/ND entry ages out due to end host inactivity or shutdown rather than a PE node or link failure, PEs which advertised a proxy MAC-IP will still follow the same procedures as above and retain their proxy MAC-IP advertisements until the age-time for the proxy MAC-IP has passed. Implementations may allow the proxy MAC-IP age-time to be administratively specified separately from the regular system ARP/ND age-time to tune how fast stale proxy MAC-IP advertisements are cleared from the EVPN. Additionally, a PE may optionally use a mechanism like send-refresh, as outlined in Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Network [RFC9161], to probe the liveness of the MAC-IP and withdraw the proxy MAC-IP from the control plane before the age-time if the PE determines that the MAC-IP is no longer active. Some implemetations may alleviate such delay by verifying the presence of associated EVPN Ethernet Auto-Discovery per ES route, also known as the mass-withdraw route. With the presence of the mass-withdraw route, a PE may decide to remove the MAC-IP immediately to avoid potential traffic loss.¶
A heterogenous mix of new PEs supporting proxy MAC-IP advertisement and legacy PEs not supporting proxy MAC-IP advertisement is supported in the event of incremental configuration of the feature or incremental upgrades of PEs attached to the same ethernet segment. Although legacy PE devices will continue to operate with the traditional mechanisms and advertise only locally learned MAC-IP entries, they can make use of any remotely learned proxy MAC-IP advertised by other PEs supporting proxy advertisement. The proxy flag does not have any impact on the best path selection of EVPN MAC/IP Advertisement routes, as outlined in [I-D.ietf-bess-rfc7432bis].¶
If the signaling of P/B flags is used along with the Ethernet A-D per EVI routes, as it is specified in [I-D.ietf-bess-rfc7432bis], and the remote PE is capable of processing P/B flags, proxy MAC-IP advertisement mechanism can be utilized in the single-active multihoming case. Otherwise, proxy MAC-IP advertisement is not applicable to ethernet segments configured for single-active multihoming because MAC advertisements are the indication of which multihoming PE is the DF for remote PEs not directly connected ethernet segment. Advertisement of a proxy MAC-IP by a non-DF multihoming PE will prevent remote PEs not directly attached to the ethernet segment from determining the correct DF.¶
When a PE advertises a proxy MAC-IP that was originally learned from the control plane with a MAC mobility extended community attached with a nonzero sequence number, the PE should advertise the new proxy MAC-IP with the same sequence number as originally received. When receiving a proxy MAC-IP with a higher sequence number, PE not attached to the same multihoming Ethernet segment withdraws its corresponding MAC-IP route regardless the state of proxy bit in its original advertisement.¶
When a PE advertises a proxy MAC-IP for an IPv6 address learned from the control plane that has the 'R' or 'O' bits set in the EVPN ND extended community, the new proxy MAC-IP should carry an EVPN ND extended community with the same 'R' and 'O' bits as originally received.¶
When a PE advertises a proxy MAC-IP, it may check the configuration of the corresponding local IRB interface to determine whether IRB is operating in symmetric or asymmetric mode. In the case of symmetric IRB, the advertising PE may set the MPLS Label2 field of the MAC/IP advertisement route to either an MPLS label or a VNI corresponding to the MAC-IP's IP-VRF on the PE. When the MPLS Label2 field is populated with a VNI, the PE should additionally include the Router's MAC Extended Community carrying the MAC address of the PE originating the MAC-IP proxy advertisement.¶
As described in section 3 above, all hosts connected to an ES are advertised by at least one PE without the proxy indication set and also by any number of additional PEs with the proxy indication set. A remote PE can then import the proxy and non-proxy MAC-IP advertisements into its IP-VRF and use the MPLS label or VNI carried in the MPLS Label2 field of the MAC-IP advertisements to route IP traffic to hosts connected to the ES.¶
This approach does not utilize the multihoming aliasing mechanism which is provided by the ESI carried in the MAC/IP advertisement routes. Instead, IP route programming is based purely on normal IP multipath procedures using the routes imported to the IP-VRFs on remote PEs.¶
EVPN already defined EVPN ARP/ND Extended Community in Propagation of ARP/ND Flags in an Ethernet Virtual Private Network [RFC9047]. This document proposes an additional bit from the flags field of that community to signal the proxy advertisement state.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x08 |Reserve|I|P|O|R| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
The following bits in the flags field in the third octet of the extended community are defined. The remaining bits must be set to zero when sending and must be ignored when receiving this community.¶
| Bit Name | Meaning |
|---|---|
| I,O,R | Defined in Propagation of ARP/ND Flags in an Ethernet Virtual Private Network [RFC9047]. |
| P | Proxy MAC-IP advertisement defined in this document |
This document requests IANA the allocation of the flag position 5 in the ARP/ND Extended Community Flags registry located in the "Border Gateway Protocol (BGP) Extended Communities" registry.¶
Flag Position Name Reference
5 Proxy MAC-IP This document
¶
Depending on the number of multihoming PEs and MAC/IP scaling of an EVPN, proxy advertisement of MAC-IP entries by other PEs in addition to the devices initially learning MAC-IP entries locally in the data plane could cause scalability concerns for operators. Proxy advertisements would increase the total number of EVPN routes maintained in the route tables of PEs, as well as increase the time required for PEs to download all remotely learned EVPN routes. Protocol implementations should provide administrative controls for operators to limit proxy advertisement functionality to situations where the benefits are required and the scale overhead is acceptable.¶
Proxy MAC-IP advertisment may potentially increase the total number of EVPN routes maintained in the control plane as it is specified in Section 6. Protocol implementations should provide administrative controls for operators to limit proxy advertisement functionality to situations where the benefits are required and the scale overhead is acceptable. Apart from that, this draft does not introduce any new security considerations to EVPN.¶