Internet DRAFT - draft-rbickhart-evpn-ip-mac-proxy-adv

draft-rbickhart-evpn-ip-mac-proxy-adv







BESS Workgroup                                               R. Bickhart
Internet-Draft                                                    Twitch
Intended status: Standards Track                                  W. Lin
Expires: 5 September 2024                               Juniper Networks
                                                                J. Drake
                                                             Independent
                                                              J. Rabadan
                                                                   Nokia
                                                                   A. Lo
                                                         Arista Networks
                                                             P. Brissete
                                                                   Cisco
                                                            4 March 2024


                  Proxy MAC-IP Advertisement in EVPNs
                draft-rbickhart-evpn-ip-mac-proxy-adv-02

Abstract

   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.

Status of This Memo

   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 5 September 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Bickhart, et al.        Expires 5 September 2024                [Page 1]

Internet-Draft     Proxy MAC-IP Advertisement in EVPNs        March 2024


   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.

Table of Contents

   1.  Conventions and Terminology . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  MAC-IP Proxy Advertisements . . . . . . . . . . . . . . . . .   3
     3.1.  Interoperation with Legacy PEs  . . . . . . . . . . . . .   5
     3.2.  Single-Active Multihoming Considerations  . . . . . . . .   5
     3.3.  MAC Route Attribute Considerations  . . . . . . . . . . .   6
     3.4.  Symmetric IRB Considerations  . . . . . . . . . . . . . .   6
   4.  EVPN ARP/ND Extended Community  . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Conventions and Terminology

   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].






Bickhart, et al.        Expires 5 September 2024                [Page 2]

Internet-Draft     Proxy MAC-IP Advertisement in EVPNs        March 2024


2.  Introduction

   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.

3.  MAC-IP Proxy Advertisements

   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



Bickhart, et al.        Expires 5 September 2024                [Page 3]

Internet-Draft     Proxy MAC-IP Advertisement in EVPNs        March 2024


   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.




Bickhart, et al.        Expires 5 September 2024                [Page 4]

Internet-Draft     Proxy MAC-IP Advertisement in EVPNs        March 2024


   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.

3.1.  Interoperation with Legacy PEs

   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].

3.2.  Single-Active Multihoming Considerations

   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.





Bickhart, et al.        Expires 5 September 2024                [Page 5]

Internet-Draft     Proxy MAC-IP Advertisement in EVPNs        March 2024


3.3.  MAC Route Attribute Considerations

   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.

3.4.  Symmetric IRB Considerations

   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.









Bickhart, et al.        Expires 5 September 2024                [Page 6]

Internet-Draft     Proxy MAC-IP Advertisement in EVPNs        March 2024


4.  EVPN ARP/ND Extended Community

   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                                     |
        +----------+----------------------------------------------+

               Table 1: EVPN ARP/ND Extended Community Flags

5.  IANA Considerations

   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












Bickhart, et al.        Expires 5 September 2024                [Page 7]

Internet-Draft     Proxy MAC-IP Advertisement in EVPNs        March 2024


6.  Operational Considerations

   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.

7.  Security Considerations

   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.

8.  Normative References

   [I-D.ietf-bess-rfc7432bis]
              Sajassi, A., Burdet, L. A., Drake, J., and J. Rabadan,
              "BGP MPLS-Based Ethernet VPN", Work in Progress, Internet-
              Draft, draft-ietf-bess-rfc7432bis-08, 13 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              rfc7432bis-08>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC9047]  Rabadan, J., Ed., Sathappan, S., Nagaraj, K., and W. Lin,
              "Propagation of ARP/ND Flags in an Ethernet Virtual
              Private Network (EVPN)", RFC 9047, DOI 10.17487/RFC9047,
              June 2021, <https://www.rfc-editor.org/info/rfc9047>.





Bickhart, et al.        Expires 5 September 2024                [Page 8]

Internet-Draft     Proxy MAC-IP Advertisement in EVPNs        March 2024


   [RFC9161]  Rabadan, J., Ed., Sathappan, S., Nagaraj, K., Hankins, G.,
              and T. King, "Operational Aspects of Proxy ARP/ND in
              Ethernet Virtual Private Networks", RFC 9161,
              DOI 10.17487/RFC9161, January 2022,
              <https://www.rfc-editor.org/info/rfc9161>.

Authors' Addresses

   Ryan Bickhart
   Twitch
   Email: rbickhar@twitch.tv


   Wen Lin
   Juniper Networks
   Email: wlin@juniper.net


   John Drake
   Independent
   Email: je_drake@yahoo.com


   Jorge Rabadan
   Nokia
   Email: jorge.rabadan@nokia.com


   Alton Lo
   Arista Networks
   Email: altonlo@arista.com


   Patrice Brissete
   Cisco
   Email: pbrisset@cisco.com















Bickhart, et al.        Expires 5 September 2024                [Page 9]