draft-ietf-bess-evpn-proxy-arp-nd-05.txt   draft-ietf-bess-evpn-proxy-arp-nd-06.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
G. Hankins G. Hankins
Nokia Nokia
T. King T. King
D. Melzer D. Melzer
DE-CIX DE-CIX
E. Nordmark E. Nordmark
Individual Individual
Expires: May 9, 2019 November 5, 2018 Expires: October 27, 2019 April 25, 2019
Operational Aspects of Proxy-ARP/ND in EVPN Networks Operational Aspects of Proxy-ARP/ND in EVPN Networks
draft-ietf-bess-evpn-proxy-arp-nd-05 draft-ietf-bess-evpn-proxy-arp-nd-06
Abstract Abstract
The EVPN MAC/IP Advertisement route can optionally carry IPv4 and The EVPN MAC/IP Advertisement route can optionally carry IPv4 and
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 (or 'unicast-forward' them to the IPv6 Neighbor Solicitation messages (or 'unicast-forward' them to the
owner of the MAC) and reduce/suppress the flooding produced by the owner of the MAC) and reduce/suppress the flooding produced by the
Address Resolution procedure. This EVPN capability is extremely Address Resolution procedure. This EVPN capability is extremely
useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with
skipping to change at page 2, line 13 skipping to change at page 2, line 13
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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." The list material or to cite them other than as "work in progress." The list
of current Internet-Drafts can be accessed at 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 May 9, 2019. This Internet-Draft will expire on October 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 44 skipping to change at page 2, line 44
2.1. The DC Use-Case . . . . . . . . . . . . . . . . . . . . . . 5 2.1. The DC Use-Case . . . . . . . . . . . . . . . . . . . . . . 5
2.2. The IXP Use-Case . . . . . . . . . . . . . . . . . . . . . 5 2.2. The IXP Use-Case . . . . . . . . . . . . . . . . . . . . . 5
3. Solution Requirements . . . . . . . . . . . . . . . . . . . . . 6 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . . 6
4. Solution Description . . . . . . . . . . . . . . . . . . . . . 7 4. Solution Description . . . . . . . . . . . . . . . . . . . . . 7
4.1. Learning Sub-Function . . . . . . . . . . . . . . . . . . . 9 4.1. Learning Sub-Function . . . . . . . . . . . . . . . . . . . 9
4.1.1. Proxy-ND and the NA Flags . . . . . . . . . . . . . . . 10 4.1.1. Proxy-ND and the NA Flags . . . . . . . . . . . . . . . 10
4.2. Reply Sub-Function . . . . . . . . . . . . . . . . . . . . 11 4.2. Reply Sub-Function . . . . . . . . . . . . . . . . . . . . 11
4.3. Unicast-forward Sub-Function . . . . . . . . . . . . . . . 12 4.3. Unicast-forward Sub-Function . . . . . . . . . . . . . . . 12
4.4. Maintenance Sub-Function . . . . . . . . . . . . . . . . . 13 4.4. Maintenance Sub-Function . . . . . . . . . . . . . . . . . 13
4.5. Flooding (to Remote PEs) Reduction/Suppression . . . . . . 14 4.5. Flooding (to Remote PEs) Reduction/Suppression . . . . . . 14
4.6. Duplicate IP Detection . . . . . . . . . . . . . . . . . . 14 4.6. Duplicate IP Detection . . . . . . . . . . . . . . . . . . 15
5. Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . 16 5. Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . 17
6. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 17 6. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 17
6.1. All Dynamic Learning . . . . . . . . . . . . . . . . . . . 17 6.1. All Dynamic Learning . . . . . . . . . . . . . . . . . . . 17
6.2. Dynamic Learning with Proxy-ARP/ND . . . . . . . . . . . . 17 6.2. Dynamic Learning with Proxy-ARP/ND . . . . . . . . . . . . 18
6.3. Hybrid Dynamic Learning and Static Provisioning with 6.3. Hybrid Dynamic Learning and Static Provisioning with
Proxy-ARP/ND . . . . . . . . . . . . . . . . . . . . . . . 18 Proxy-ARP/ND . . . . . . . . . . . . . . . . . . . . . . . 18
6.4 All Static Provisioning with Proxy-ARP/ND . . . . . . . . . 18 6.4 All Static Provisioning with Proxy-ARP/ND . . . . . . . . . 18
6.5 Deployment Scenarios in IXPs . . . . . . . . . . . . . . . . 18 6.5 Deployment Scenarios in IXPs . . . . . . . . . . . . . . . . 18
6.6 Deployment Scenarios in DCs . . . . . . . . . . . . . . . . 19 6.6 Deployment Scenarios in DCs . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Terminology 1. Terminology
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 "OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 9, line 16 skipping to change at page 9, line 16
A Proxy-ARP/ND implementation MAY support all those sub-functions or A Proxy-ARP/ND implementation MAY support all those sub-functions or
only a subset of them. The following sections describe each only a subset of them. The following sections describe each
individual sub-function. individual sub-function.
4.1. Learning Sub-Function 4.1. Learning Sub-Function
A Proxy-ARP/ND implementation SHOULD support static, dynamic and A Proxy-ARP/ND implementation SHOULD support static, dynamic and
EVPN-learned entries. EVPN-learned entries.
Static entries are provisioned from the management plane. The Static entries are provisioned from the management plane. The
provisioned static IP->MAC entry SHOULD be advertised in EVPN with a provisioned static IP->MAC entry SHOULD be advertised in EVPN with an
MAC Mobility extended community where the static flag is set to 1, as ARP/ND extended community where the Immutable ARP/ND Binding Flag
per [RFC7432]. A static entry MAY associate and IP to a list of flag (I) is set to 1, as per [EVPN-ND-FLAGS]. When the I flag in the
potential MACs, i.e. IP1->(MAC1,MAC2..MACN). When there is more than ARP/ND extended community is 1, the advertising PE indicates that the
one MAC in the list of allowed MACs, the PE will not advertise any IP address MUST NOT be associated to a MAC, other than the one
IP->MAC in EVPN until a local ARP/NA message or any other frame is included in the MAC/IP route. The advertisement of I=1 in the ARP/ND
received from the CE. Upon receiving traffic from the CE, the PE will extended community is compatible with any value of the Sticky bit (S)
check that the source MAC is included in the list of allowed MACs. or Sequence Number in the [RFC7432] MAC Mobility extended community.
Only in that case, the PE will activate the IP->MAC and advertise it Note that the I bit in the ARP/ND extended community refers to the
in EVPN. immutable configured association between the IP and the MAC address
in the IP->MAC binding, whereas the S bit in the MAC Mobility
extended community refers to the fact that the advertised MAC address
is not subject to the [RFC7432] mobility procedures.
An entry MAY associate a configured static IP to a list of potential
MACs, i.e. IP1->(MAC1,MAC2..MACN). When there is more than one MAC in
the list of allowed MACs, the PE will not advertise any IP->MAC in
EVPN until a local ARP/NA message or any other frame is received from
the CE. Upon receiving traffic from the CE, the PE will check that
the source MAC is included in the list of allowed MACs. Only in that
case, the PE will activate the IP->MAC and advertise it in EVPN.
EVPN-learned entries MUST be learned from received valid EVPN MAC/IP EVPN-learned entries MUST be learned from received valid EVPN MAC/IP
Advertisement routes containing a MAC and IP address. Advertisement routes containing a MAC and IP address.
Dynamic entries are learned in different ways depending on whether Dynamic entries are learned in different ways depending on whether
the entry contains an IPv4 or IPv6 address: the entry contains an IPv4 or IPv6 address:
a) Proxy-ARP dynamic entries: a) Proxy-ARP dynamic entries:
They SHOULD be learned by snooping any ARP packet (Ethertype They SHOULD be learned by snooping any ARP packet (Ethertype
skipping to change at page 15, line 23 skipping to change at page 15, line 32
MAC duplication function supported by [RFC7432] for MAC addresses. MAC duplication function supported by [RFC7432] for MAC addresses.
Duplicate IP detection monitors "IP-moves" in the Proxy-ARP/ND table Duplicate IP detection monitors "IP-moves" in the Proxy-ARP/ND table
in the following way: in the following way:
o When an existing active IP1->MAC1 entry is modified, a PE starts an o When an existing active IP1->MAC1 entry is modified, a PE starts an
M-second timer (default value of M=180), and if it detects N IP M-second timer (default value of M=180), and if it detects N IP
moves before the timer expires (default value of N=5), it concludes moves before the timer expires (default value of N=5), it concludes
that a duplicate IP situation has occurred. An IP move is that a duplicate IP situation has occurred. An IP move is
considered when, for instance, IP1->MAC1 is replaced by IP1->MAC2 considered when, for instance, IP1->MAC1 is replaced by IP1->MAC2
in the Proxy-ARP/ND table. in the Proxy-ARP/ND table. Static IP->MAC entries, that is, locally
provisioned or EVPN-learned entries (with I=1 in the ARP/ND
extended community), are not subject to this procedure. Static
entries MUST NOT be overridden by dynamic Proxy-ARP/ND entries.
o In order to detect the duplicate IP faster, the PE MAY send a o In order to detect the duplicate IP faster, the PE MAY send a
CONFIRM message to the former owner of the IP. A CONFIRM message is CONFIRM message to the former owner of the IP. A CONFIRM message is
a unicast ARP-Request/NS message sent by the PE to the MAC a unicast ARP-Request/NS message sent by the PE to the MAC
addresses that previously owned the IP, when the MAC changes in the addresses that previously owned the IP, when the MAC changes in the
Proxy-ARP/ND table. The CONFIRM message uses a sender's IP 0.0.0.0 Proxy-ARP/ND table. The CONFIRM message uses a sender's IP 0.0.0.0
in case of ARP (if the PE has an IP address in the subnet then it in case of ARP (if the PE has an IP address in the subnet then it
MAY use it) and an IPv6 Link Local Address in case of NS. If the PE MAY use it) and an IPv6 Link Local Address in case of NS. If the PE
does not receive an answer within a given timer, the new entry will does not receive an answer within a given timer, the new entry will
be confirmed and activated. In case of spoofing, for instance, if be confirmed and activated. In case of spoofing, for instance, if
 End of changes. 10 change blocks. 
23 lines changed or deleted 37 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/