[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

BESS Workgroup                                               R. Bickhart
Internet-Draft                                                    W. Lin
Intended status: Standards Track                                J. Drake
Expires: September 6, 2019                              Juniper Networks
                                                              J. Rabadan
                                                                   Nokia
                                                           March 5, 2019


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

Abstract

   This document specifies procedures for EVPN PEs connected to a common
   multihomed site to generate proxy EVPN type 2 IP->MAC 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 September 6, 2019.

Copyright Notice

   Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of



Bickhart, et al.        Expires September 6, 2019               [Page 1]


Internet-Draft    Proxy IP->MAC Advertisement in EVPNs        March 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

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

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.

   IP->MAC: 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].

2.  Introduction

   EVPN [RFC7432] allows for the distribution of IP->MAC bindings of
   connected hosts learned through IPv4 ARP and IPv6 neighbor discovery
   (ND) using type 2 MAC/IP advertisement routes.  When end hosts are
   connected to a multihomed site of an EVPN running in all-active mode,
   depending on the learning mechanisms of the multihoming PEs and the
   load balancing mechanisms implemented by the CE devices multihomed to
   the EVPN PEs, local learning of an IP->MAC may be limited to a subset



Bickhart, et al.        Expires September 6, 2019               [Page 2]


Internet-Draft    Proxy IP->MAC Advertisement in EVPNs        March 2019


   of the total number of multihoming PEs, possibly only a single PE
   device.  In the steady state, the IP->MAC 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 IP->MAC 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.

   In the event of the complete failure of a multihoming PE or the
   failure of a multihoming PE's link to the multihomed site, any
   IP->MAC locally learned on that PE or locally attached link will be
   invalidated and will be withdrawn from the EVPN control plane.  If
   the source of the failure was the only origin of any particular
   IP->MAC, that IP->MAC will completely disappear from the EVPN until
   such time that one of the remaining multihoming PEs is able to
   relearn the IP->MAC that was lost.  Traffic forwarding or other EVPN
   features like ARP/ND suppression may fail during the intermediate
   period between the loss of the IP->MAC from the original local
   learning PE and later learning and distribution of the IP->MAC from a
   new local learning PE.

   This document specifies procedures to preserve IP->MAC state across
   the remaining multihoming PEs in the EVPN to bridge the gap between
   the initial failure and the subsequent relearning of the IP->MAC on
   one of the remaining multihoming PEs.

3.  IP->MAC Proxy Advertisements

   Preserving IP->MAC state in the EVPN until relearning and
   distribution of the new IP->MAC state to all PEs is completed can be
   accomplished by using IP->MAC proxy advertisements.  When an IP->MAC
   for a host connected to a multihomed site is locally learned by a PE,
   the PE will advertise the IP->MAC via an EVPN MAC/IP route as usual.
   When other PEs learn that IP->MAC from the control plane upon
   reception of the MAC/IP route, they will install the ARP/ND state
   derived from the received IP->MAC for local use as usual.
   Additionally, if the receiving PE is locally connected to the same
   multihomed ethernet segment where the received IP->MAC originated and
   the IP->MAC was not previously locally learned and advertised, the
   receiving PE will inject its own EVPN MAC/IP route carrying the same
   IP->MAC (and with the same ESI) into the control plane and mark that
   injected route with a special proxy IP->MAC 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 IP->MAC using an EVPN MAC/IP route,
   some of the route advertisements possibly carrying the proxy




Bickhart, et al.        Expires September 6, 2019               [Page 3]


Internet-Draft    Proxy IP->MAC Advertisement in EVPNs        March 2019


   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 IP->MAC state on a multihoming PE will cause
   that PE to start an aging timer for the proxy IP->MAC 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
   IP->MAC to be set administratively.  While the aging timer is
   running, the multihoming PE will take no other actions and will
   continue using the proxy IP->MAC state for local forwarding and ARP/
   ND purposes and will continue to advertise the IP->MAC 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 IP->MAC
   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
   IP->MAC locally, it will restart the aging timer for the IP->MAC with
   the default ARP/ND age-time and remove the proxy indication from the
   EVPN MAC/IP route for the IP->MAC 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
   IP->MAC, that PE will stop the aging timer for the locally advertised
   proxy IP->MAC and continue advertising the IP->MAC with the proxy
   indication set as before.

   In the event that a multihoming PE fails to learn the IP->MAC locally
   before the aging timer for the proxy IP->MAC expires, that PE will
   withdraw the EVPN MAC/IP route for proxy IP->MAC that it had
   advertised previously.  In this way, if all multihoming PEs fail to
   learn the IP->MAC locally within the age-time, the proxy IP->MAC
   advertisements will expire on every PE and will be withdrawn,
   completely removing the IP->MAC from the EVPN.

   In the case that a non-proxy IP->MAC 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 IP->MAC will still follow the
   same procedures as above and retain their proxy IP->MAC
   advertisements until the age-time has passed.  Implementations may
   allow the proxy IP->MAC age-time to be administratively specified
   separately from the regular system ARP/ND age-time to tune how fast
   stale proxy IP->MAC advertisements are cleared from the EVPN.
   Additionally, a PE may optionally use a mechanism like send-refresh



Bickhart, et al.        Expires September 6, 2019               [Page 4]


Internet-Draft    Proxy IP->MAC Advertisement in EVPNs        March 2019


   [I-D.ietf-bess-evpn-proxy-arp-nd] to probe the liveness of the
   IP->MAC and withdraw the proxy IP->MAC from the control plane before
   the age-time if the PE determines that the IP->MAC is no longer
   active.

3.1.  Interoperation with Legacy PEs

   A heterogenous mix of new PEs supporting proxy IP->MAC advertisement
   and legacy PEs not supporting proxy IP->MAC 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 IP->MAC
   entries, they can make use of any remotely learned proxy IP->MAC
   advertised by other PEs supporting proxy advertisement.

3.2.  Single-Active Multihoming Considerations

   Proxy IP->MAC 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
   IP->MAC by a non-DF multihoming PE will prevent remote PEs not
   directly attached to the ethernet segment from determining the
   correct DF.

3.3.  MAC Route Attribute Considerations

   When a PE advertises a proxy IP->MAC 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
   IP->MAC with the same sequence number as originally received.  The
   presence or lack of a proxy indication for a received IP->MAC
   advertisement should not be used in active MAC determination for MAC
   mobility purposes.

   When a PE advertises a proxy IP->MAC 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 IP->MAC should carry an EVPN ND
   extended community with the same 'R' and 'O' bits as originally
   received.

4.  EVPN ARP/ND Extended Community

   EVPN already provides an extended community to signal additional
   state relevant to IPv6 ND (the override and router bits).  Because
   the proxy indication described in this document is equally applicable
   to both ARP and ND, we propose renaming the EVPN Neighbor Discovery



Bickhart, et al.        Expires September 6, 2019               [Page 5]


Internet-Draft    Proxy IP->MAC Advertisement in EVPNs        March 2019


   (ND) Extended Community (type 0x08) to EVPN ARP/ND Extended Community
   and allocating an additional bit from the flags field of the
   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 |Reserved |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    | Meaning                                                  |
   | Name   |                                                          |
   +--------+----------------------------------------------------------+
   | O,R    | Defined in IPv6 Neighbor Advertisement Flags in EVPN     |
   |        | [I-D.ietf-bess-evpn-na-flags]                            |
   | P      | Proxy IP->MAC advertisement defined in this draft        |
   +--------+----------------------------------------------------------+

                   EVPN ARP/ND Extended Community Flags

5.  IANA Considerations

   This document requests the value of 0x04 of the EVPN ARP/ND extended
   community flags field to be assigned to the proxy IP->MAC
   advertisement (P) bit.

6.  Operational Considerations

   Depending on the number of multihoming PEs and MAC/IP scaling of an
   EVPN, proxy advertisement of IP->MAC entries by other PEs in addition
   to the devices initially learning IP->MAC 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.







Bickhart, et al.        Expires September 6, 2019               [Page 6]


Internet-Draft    Proxy IP->MAC Advertisement in EVPNs        March 2019


7.  Security Considerations

   This draft does not introduce any new security considerations to
   EVPN.

8.  Normative References

   [I-D.ietf-bess-evpn-na-flags]
              Rabadan, J., Sathappan, S., and K. Nagaraj, "Propagation
              of IPv6 Neighbor Advertisement Flags in EVPN", draft-ietf-
              bess-evpn-na-flags-02 (work in progress), October 2018.

   [I-D.ietf-bess-evpn-proxy-arp-nd]
              Rabadan, J., Sathappan, S., Nagaraj, K., Henderickx, W.,
              Hankins, G., King, T., Melzer, D., and E. Nordmark,
              "Operational Aspects of Proxy-ARP/ND in EVPN Networks",
              draft-ietf-bess-evpn-proxy-arp-nd-05 (work in progress),
              November 2018.

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

Authors' Addresses

   Ryan Bickhart
   Juniper Networks

   Email: rbickhart@juniper.net


   Wen Lin
   Juniper Networks

   Email: wlin@juniper.net


   John Drake
   Juniper Networks

   Email: jdrake@juniper.net




Bickhart, et al.        Expires September 6, 2019               [Page 7]


Internet-Draft    Proxy IP->MAC Advertisement in EVPNs        March 2019


   Jorge Rabadan
   Nokia

   Email: jorge.rabadan@nokia.com















































Bickhart, et al.        Expires September 6, 2019               [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/