< draft-ietf-bess-evpn-na-flags-03.txt   draft-ietf-bess-evpn-na-flags-04.txt >
BESS Workgroup J. Rabadan, Ed. BESS Workgroup J. Rabadan, Ed.
Internet Draft S. Sathappan Internet Draft S. Sathappan
K. Nagaraj K. Nagaraj
Intended status: Standards Track Nokia Intended status: Standards Track Nokia
W. Lin W. Lin
Juniper Juniper
Expires: October 27, 2019 April 25, 2019 Expires: January 4, 2020 July 3, 2019
Propagation of ARP/ND Flags in EVPN Propagation of ARP/ND Flags in EVPN
draft-ietf-bess-evpn-na-flags-03 draft-ietf-bess-evpn-na-flags-04
Abstract Abstract
An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or
IPv6 addresses associated with a MAC address. Remote PEs can use this IPv6 addresses associated with a MAC address. Remote PEs can use this
information to reply locally (act as proxy) to IPv4 ARP requests and information to reply locally (act as proxy) to IPv4 ARP requests and
IPv6 Neighbor Solicitation messages and reduce/suppress the flooding IPv6 Neighbor Solicitation messages and reduce/suppress the flooding
produced by the Address Resolution procedure. The information produced by the Address Resolution procedure. The information
conveyed in the MAC/IP route may not be enough for the remote PE to conveyed in the MAC/IP route may not be enough for the remote PE to
reply to local ARP or ND requests. For example, if a PE learns an reply to local ARP or ND requests. For example, if a PE learns an
IPv6->MAC ND entry via EVPN, the PE would not know if that particular IPv6->MAC ND entry via EVPN, the PE would not know if that particular
IPv6->MAC pair belongs to a host, a router or a host with an anycast IPv6->MAC pair belongs to a host, a router or a host with an anycast
address, as this information is not carried in the MAC/IP route address, as this information is not carried in the MAC/IP route
advertisements. Similarly, other information relevant to the IP->MAC advertisements. Similarly, other information relevant to the IP->MAC
ARP/ND entries may be needed. This document proposes an OPTIONAL ARP/ND entries may be needed. This document defines an extended
extended community that is advertised along with an EVPN MAC/IP community that is advertised along with an EVPN MAC/IP Advertisement
Advertisement route and carries information relevant to the ARP/ND route and carries information relevant to the ARP/ND resolution, so
resolution, so that an EVPN PE implementing a proxy-ARP/ND function that an EVPN PE implementing a proxy-ARP/ND function can reply to ARP
can reply to ARP Requests or Neighbor Solicitations with the correct Requests or Neighbor Solicitations with the correct information.
information.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 16 skipping to change at page 2, line 14
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 27, 2019. This Internet-Draft will expire on January 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 38
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology and Conventions . . . . . . . . . . . . . . . . 3 1.1 Terminology and Conventions . . . . . . . . . . . . . . . . 3
2. The EVPN ARP/ND Extended Community . . . . . . . . . . . . . . 4 2. The EVPN ARP/ND Extended Community . . . . . . . . . . . . . . 4
3. Use of the EVPN ARP/ND Extended Community . . . . . . . . . . . 5 3. Use of the EVPN ARP/ND Extended Community . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or
IPv6 addresses associated with a MAC address. Remote PEs can use this IPv6 addresses associated with a MAC address. Remote PEs can use this
information to reply locally (act as proxy) to IPv4 ARP requests and information to reply locally (act as proxy) to IPv4 ARP requests and
IPv6 Neighbor Solicitation messages and reduce/suppress the flooding IPv6 Neighbor Solicitation messages and reduce/suppress the flooding
produced by the Address Resolution procedure. The information produced by the Address Resolution procedure. The information
conveyed in the MAC/IP route may not be enough for the remote PE to conveyed in the MAC/IP route may not be enough for the remote PE to
reply to local ARP or ND requests. For example, if a PE learns an reply to local ARP or ND requests. For example, if a PE learns an
IPv6->MAC ND entry via EVPN, the PE would not know if that particular IPv6->MAC ND entry via EVPN, the PE would not know if that particular
IPv6->MAC pair belongs to a host, a router or a host with an anycast IPv6->MAC pair belongs to a host, a router or a host with an anycast
address, as this information is not carried in the MAC/IP route address, as this information is not carried in the MAC/IP route
advertisements. Similarly, other information relevant to the host advertisements. Similarly, other information relevant to the host
advertised in the MAC/IP Advertisement route may be needed. advertised in the MAC/IP Advertisement route may be needed.
This document proposes an OPTIONAL extended community that is This document defines an extended community that is advertised along
advertised along with an EVPN MAC/IP Advertisement route and carries with an EVPN MAC/IP Advertisement route and carries information
information relevant to the ARP/ND resolution, so that an EVPN PE relevant to the ARP/ND resolution, so that an EVPN PE implementing a
implementing a proxy-ARP/ND function can reply to ARP Requests or proxy-ARP/ND function can reply to ARP Requests or Neighbor
Neighbor Solicitations with the correct information. In particular, Solicitations with the correct information. In particular, the Flags
the Flags defined in [RFC4861] can now be conveyed along with a defined in [RFC4861] can now be conveyed along with a MAC/IP
MAC/IP Advertisement route, so that an egress EVPN PE can issue Advertisement route, so that an egress EVPN PE can issue Neighbor
Neighbor Advertisement messages with the correct Flag information. Advertisement messages with the correct Flag information.
The Flags are carried in the EVPN Address Resolution Protocol (ARP) The Flags are carried in the EVPN Address Resolution Protocol (ARP)
and Neighbor Discovery (ND) Extended Community, as described in the and Neighbor Discovery (ND) Extended Community, as described in the
following sections. following sections.
1.1 Terminology and Conventions 1.1 Terminology and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 4, line 4 skipping to change at page 4, line 4
BD: Broadcast Domain, also described in [RFC7432]. BD: Broadcast Domain, also described in [RFC7432].
IP->MAC: refers to an IP address and MAC address combination that IP->MAC: refers to an IP address and MAC address combination that
represents a given host and is added to an Address Resolution represents a given host and is added to an Address Resolution
Protocol table or Neighbor Discovery table. This document uses IP- Protocol table or Neighbor Discovery table. This document uses IP-
>MAC generically for IPv4 and IPv6 addresses. When something is >MAC generically for IPv4 and IPv6 addresses. When something is
specific to IPv4, the document will use IPv4->MAC and likewise, IPv6- specific to IPv4, the document will use IPv4->MAC and likewise, IPv6-
>MAC will be used when something is specific to IPv6 entries only. >MAC will be used when something is specific to IPv6 entries only.
Proxy-ARP/ND: refers to a function on the EVPN PEs by which received Proxy-ARP/ND: refers to a function on the EVPN PEs by which received
Address Resolution Protocol (ARP) Requests or Neighbor Discovery (ND) Address Resolution Protocol (ARP) Requests or Neighbor Solicitation
- or Neighbor Solicitation (NS) - messages are replied locally by the (NS) messages are replied locally by the PE, without the need to
PE, without the need to flood the requests to remote PEs in the BD. flood the requests to remote PEs in the BD. In order to reply to ARP
In order to reply to ARP Requests or NS messages, the PE does a Requests or NS messages, the PE does a lookup on an ARP/ND table,
lookup on an ARP/ND table, that is a collection of IP->MAC entries that is a collection of IP->MAC entries learned by the PE.
learned by the PE.
Familiarity with the terminology in [RFC7432] and [RFC4861] is Familiarity with the terminology in [RFC7432] and [RFC4861] is
expected. expected.
2. The EVPN ARP/ND Extended Community 2. The EVPN ARP/ND Extended Community
This document defines a new EVPN Extended Community with a Type field This document defines a new EVPN Extended Community with a Type field
value of 0x06 and a Sub-Type 0x08, as allocated by IANA. It MAY be value of 0x06 and a Sub-Type 0x08, as allocated by IANA. It is
advertised along with EVPN MAC/IP Advertisement routes that carry an advertised along with EVPN MAC/IP Advertisement routes that carry an
IPv4 or IPv6 address. IPv4 or IPv6 address.
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 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= TBD |Flags (1 octet)| Reserved=0 | | Type=0x06 | Sub-Type= TBD |Flags (1 octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 27 skipping to change at page 5, line 27
flag". When set, the egress PE indicates that the IP->MAC pair sent flag". When set, the egress PE indicates that the IP->MAC pair sent
in a MAC/IP route along with the extended community is a configured in a MAC/IP route along with the extended community is a configured
ARP/ND entry, and the IP address in the MAC/IP route can only be ARP/ND entry, and the IP address in the MAC/IP route can only be
bound together with the MAC address specified in the same route. bound together with the MAC address specified in the same route.
Bits 0-3 and 5 are not assigned by this document. Bits 0-3 and 5 are not assigned by this document.
3. Use of the EVPN ARP/ND Extended Community 3. Use of the EVPN ARP/ND Extended Community
An EVPN PE supporting a ND/ARP function and implementing the An EVPN PE supporting a ND/ARP function and implementing the
propagation of the ARP/ND Flags will follow this procedure: propagation of the ARP/ND Flags MUST follow this procedure:
a) Transmission of the EVPN ARP/ND Extended Community a) Transmission of the EVPN ARP/ND Extended Community
A PE may learn the IPv6->MAC pair and its associated ND Flags in the A PE may learn the IPv6->MAC pair and its associated ND Flags in the
management plane or snooping Neighbor Advertisement messages coming management plane or by snooping Neighbor Advertisement messages
from the CE. Either way, the PE SHOULD send a MAC/IP Advertisement coming from the CE. Either way, the PE sends a MAC/IP Advertisement
route including the learned IPv6->MAC pair and MAY send the ARP/ND route including the learned IPv6->MAC pair and MUST send the ARP/ND
Extended Community carrying its associated "R" and "O" Flags. Extended Community carrying its associated "R" and "O" Flags.
If an IPv4->MAC or IPv6->MAC pair has been learned in the management If an IPv4->MAC or IPv6->MAC pair has been learned in the management
plane (it has been configured) the corresponding MAC/IP Advertisement plane (it has been configured) the corresponding MAC/IP Advertisement
route SHOULD be sent along with an ARP/ND extended community with the route SHOULD be sent along with an ARP/ND extended community with the
flag I set. flag I set.
This Extended Community does not have any impact on the rest of the This Extended Community does not have any impact on the rest of the
procedures described in [RFC7432], including the advertisement of the procedures described in [RFC7432], including the advertisement of the
MAC Mobility Extended Community along with the MAC/IP Advertisement MAC Mobility Extended Community along with the MAC/IP Advertisement
route. route.
b) Reception of the EVPN ARP/ND Extended Community b) Reception of the EVPN ARP/ND Extended Community
In addition to the procedures specified in [RFC7432] a PE receiving a In addition to the procedures specified in [RFC7432] a PE receiving a
MAC/IP Advertisement route containing an IPv6 address and the ND MAC/IP Advertisement route containing an IPv6 address and the ND
Extended Community SHOULD add the R and O Flags to the ND entry for Extended Community MUST add the R and O Flags to the ND entry for the
the IPv6->MAC entry and use that information in Neighbor IPv6->MAC entry and use that information in Neighbor Advertisements
Advertisements when replying to a Solicitation for the IPv6 address. when replying to a Solicitation for the IPv6 address.
A PE that implements a proxy-ND function SHOULD have an A PE that implements a proxy-ND function SHOULD have an
administrative option to define the default Flag to be used in case administrative option to define the default Flag to be used in case
no EVPN ND Extended Community is received for a given IPv6->MAC no EVPN ND Extended Community is received for a given IPv6->MAC
entry. A PE MUST ignore the received R and O Flags for a MAC/IP route entry. A PE MUST ignore the received R and O Flags for a MAC/IP route
that contains an IPv4 address. that contains an IPv4 address.
A PE receiving a MAC/IP Advertisement route containing an IPv4 or A PE receiving a MAC/IP Advertisement route containing an IPv4 or
IPv6 address and the I flag set, SHOULD install the IP->MAC entry in IPv6 address and the I flag set, SHOULD install the IP->MAC entry in
the ARP/ND table as "Immutable binding" entry. the ARP/ND table as "Immutable binding" entry.
skipping to change at page 6, line 37 skipping to change at page 6, line 37
PE1 originates a MAC/IP route for IP1->MAC1 with I=1; later on, PE2 PE1 originates a MAC/IP route for IP1->MAC1 with I=1; later on, PE2
also originates a MAC/IP route IP1->MAC1 with a higher sequence also originates a MAC/IP route IP1->MAC1 with a higher sequence
number and I=1. Then all the EVPN PEs attached to the same BD SHOULD number and I=1. Then all the EVPN PEs attached to the same BD SHOULD
retain their IP1->MAC1 ARP/ND binding but update MAC1's forwarding retain their IP1->MAC1 ARP/ND binding but update MAC1's forwarding
destination to PE2. If for some reason, PE3 originates a MAC/IP route destination to PE2. If for some reason, PE3 originates a MAC/IP route
for IP1->MAC2 (even with a higher sequence number), then the EVPN PEs for IP1->MAC2 (even with a higher sequence number), then the EVPN PEs
in the BD SHOULD NOT update their IP1->MAC1 ARP/ND bindings, since in the BD SHOULD NOT update their IP1->MAC1 ARP/ND bindings, since
IP1 is bound to MAC1 (MAC2 SHOULD still be programmed in the layer-2 IP1 is bound to MAC1 (MAC2 SHOULD still be programmed in the layer-2
BDs). This is considered a misconfiguration in PE3. BDs). This is considered a misconfiguration in PE3.
A PE originating a MAC/IP route for IP1->MAC1 with I=1 may also A PE originating a MAC/IP route for IP1->MAC1 with I=1 MAY also
originate the route with the Static bit set (in the MAC Mobility originate the route with the Static bit set (in the MAC Mobility
extended community). In such a case, the IP1->MAC1 binding is not extended community). In such a case, the IP1->MAC1 binding is not
only immutable but it cannot move as well. only immutable but it cannot move as well. Also, note that the use of
the flag I=1 assumes that a given IP is always bound to the same MAC
address, and therefore some of the mobility procedures described in
[EXT-MOBILITY] will not apply.
The flags SHOULD be ignored if they are advertised along with a The flags SHOULD be ignored if they are advertised along with a
MAC/IP Advertisement route that does not contain an IP address. MAC/IP Advertisement route that does not contain an IP address.
4. Security Considerations 4. Security Considerations
The same security considerations described in [RFC7432] apply to this The same security considerations described in [RFC7432] apply to this
document. document.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 7, line 23 skipping to change at page 7, line 27
made: made:
Flag position Name Reference Flag position Name Reference
0-3 Unassigned 0-3 Unassigned
4 Immutable ARP/ND Binding Flag (I) [this document] 4 Immutable ARP/ND Binding Flag (I) [this document]
5 Unassigned 5 Unassigned
6 Override Flag (O) [this document] 6 Override Flag (O) [this document]
7 Router Flag (R) [this document] 7 Router Flag (R) [this document]
The registration procedure for this registry is Standards Action.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI
10.17487/RFC4861, September 2007, <https://www.rfc- 10.17487/RFC4861, September 2007, <https://www.rfc-
editor.org/info/rfc4861>. editor.org/info/rfc4861>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
skipping to change at page 7, line 47 skipping to change at page 8, line 7
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997, <https://www.rfc-editor.org/info/rfc2119>. 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC2119 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC2119
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>. <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References 6.2. Informative References
[EXT-MOBILITY] Malhotra, N. et al., "Extended Mobility Procedures for
EVPN-IRB", Work in Progress, draft-ietf-bess-evpn-irb-extended-
mobility-01, June 2019.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Ali Sajassi for his feedback.
Authors' Addresses Authors' Addresses
Jorge Rabadan (Editor) Jorge Rabadan (Editor)
Nokia Nokia
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Senthil Sathappan Senthil Sathappan
Nokia Nokia
 End of changes. 17 change blocks. 
36 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/