draft-ietf-bess-evpn-proxy-arp-nd-06.txt   draft-ietf-bess-evpn-proxy-arp-nd-07.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: Informational W. Henderickx Intended status: Informational G. Hankins
G. Hankins
Nokia Nokia
T. King T. King
D. Melzer
DE-CIX DE-CIX
E. Nordmark Expires: January 9, 2020 July 8, 2019
Individual
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-06 draft-ietf-bess-evpn-proxy-arp-nd-07
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 9
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 October 27, 2019. This Internet-Draft will expire on January 9, 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 3, line 4 skipping to change at page 2, line 47
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 . . . . . . . . . . . . . . . . . . 15 4.6. Duplicate IP Detection . . . . . . . . . . . . . . . . . . 15
5. Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . 20 6.6 Deployment Scenarios in DCs . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 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 18 skipping to change at page 9, line 16
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 an provisioned static IP->MAC entry SHOULD be advertised in EVPN with an
ARP/ND extended community where the Immutable ARP/ND Binding Flag ARP/ND extended community where the Immutable ARP/ND Binding Flag
flag (I) is set to 1, as per [EVPN-ND-FLAGS]. When the I flag in the flag (I) is set to 1, as per [EVPN-ARP-ND-FLAGS]. When the I flag in
ARP/ND extended community is 1, the advertising PE indicates that the the ARP/ND extended community is 1, the advertising PE indicates that
IP address MUST NOT be associated to a MAC, other than the one the IP address MUST NOT be associated to a MAC, other than the one
included in the MAC/IP route. The advertisement of I=1 in the ARP/ND included in the MAC/IP route. The advertisement of I=1 in the ARP/ND
extended community is compatible with any value of the Sticky bit (S) extended community is compatible with any value of the Sticky bit (S)
or Sequence Number in the [RFC7432] MAC Mobility extended community. or Sequence Number in the [RFC7432] MAC Mobility extended community.
Note that the I bit in the ARP/ND extended community refers to the Note that the I bit in the ARP/ND extended community refers to the
immutable configured association between the IP and the MAC address immutable configured association between the IP and the MAC address
in the IP->MAC binding, whereas the S bit in the MAC Mobility in the IP->MAC binding, whereas the S bit in the MAC Mobility
extended community refers to the fact that the advertised MAC address extended community refers to the fact that the advertised MAC address
is not subject to the [RFC7432] mobility procedures. is not subject to the [RFC7432] mobility procedures.
An entry MAY associate a configured static IP to a list of potential An entry MAY associate a configured static IP to a list of potential
skipping to change at page 10, line 20 skipping to change at page 10, line 18
implementation SHOULD NOT learn IP->MAC entries from NS messages, implementation SHOULD NOT learn IP->MAC entries from NS messages,
since they don't contain the R-bit Flag required by the Proxy-ND since they don't contain the R-bit Flag required by the Proxy-ND
reply function. See section 4.1.1 for more information about the reply function. See section 4.1.1 for more information about the
R-bit flag. R-bit flag.
Note that if the O-bit is zero in the received NA message, the Note that if the O-bit is zero in the received NA message, the
IP->MAC SHOULD only be learned in case IPv6 'anycast' is enabled IP->MAC SHOULD only be learned in case IPv6 'anycast' is enabled
in the EVI. in the EVI.
The following procedure associated to the Learning sub-function is The following procedure associated to the Learning sub-function is
recommended: RECOMMENDED:
o When a new Proxy-ARP/ND EVPN or static active entry is learned (or o When a new Proxy-ARP/ND EVPN or static active entry is learned (or
provisioned), the PE SHOULD send an unsolicited GARP or NA message provisioned), the PE SHOULD send an unsolicited GARP or NA message
to the access CEs. The PE SHOULD send an unsolicited GARP/NA to the access CEs. The PE SHOULD send an unsolicited GARP/NA
message for dynamic entries only if the ARP/NA message creating the message for dynamic entries only if the ARP/NA message creating the
entry was NOT flooded before. This unsolicited GARP/NA message entry was NOT flooded before. This unsolicited GARP/NA message
makes sure the CE ARP/ND caches are updated even if the ARP/NS/NA makes sure the CE ARP/ND caches are updated even if the ARP/NS/NA
messages from remote CEs are not flooded in the EVPN network. messages from remote CEs are not flooded in the EVPN network.
Note that if a Static entry is provisioned with the same IP as an Note that if a Static entry is provisioned with the same IP as an
skipping to change at page 11, line 24 skipping to change at page 11, line 22
o Static entries SHOULD have the R-bit information added by the o Static entries SHOULD have the R-bit information added by the
management interface. The O-bit information MAY also be added by management interface. The O-bit information MAY also be added by
the management interface. the management interface.
o Dynamic entries SHOULD learn the R-bit and MAY learn the O-bit from o Dynamic entries SHOULD learn the R-bit and MAY learn the O-bit from
the snooped NA messages used to learn the IP->MAC itself. the snooped NA messages used to learn the IP->MAC itself.
o EVPN-learned entries SHOULD learn the R-bit and MAY learn the O-bit o EVPN-learned entries SHOULD learn the R-bit and MAY learn the O-bit
from the ND Extended Community received from EVPN along with the from the ND Extended Community received from EVPN along with the
RT2 used to learn the IP->MAC itself. Please refer to [EVPN-NA- RT2 used to learn the IP->MAC itself. Please refer to [EVPN-ARP-ND-
FLAGS]. If no ND extended community is received, the PE will add FLAGS]. If no ND extended community is received, the PE will add
the default R-bit/O-bit to the entry. The default R-bit SHOULD be the default R-bit/O-bit to the entry. The default R-bit SHOULD be
an administrative choice. The default O-bit SHOULD be 1. an administrative choice. The default O-bit SHOULD be 1.
Note that the O-bit SHOULD only be learned if 'anycast' is enabled in Note that the O-bit SHOULD only be learned if 'anycast' is enabled in
the EVI. If so, Duplicate IP Detection must be disabled so that the the EVI. If so, Duplicate IP Detection must be disabled so that the
PE is able to learn the same IP mapped to different MACs in the same PE is able to learn the same IP mapped to different MACs in the same
Proxy-ND table. If 'anycast' is disabled, NA messages with O-bit = 0 Proxy-ND table. If 'anycast' is disabled, NA messages with O-bit = 0
will not create a Proxy-ND entry, hence no EVPN advertisement with ND will not create a Proxy-ND entry, hence no EVPN advertisement with ND
extended community will be generated. extended community will be generated.
4.2. Reply Sub-Function 4.2. Reply Sub-Function
This sub-function will reply to Address Resolution This sub-function will reply to Address Resolution
requests/solicitations upon successful lookup in the Proxy-ARP/ND requests/solicitations upon successful lookup in the Proxy-ARP/ND
table for a given IP address. The following considerations should be table for a given IP address. The following considerations should be
taken into account: taken into account:
a) When replying to ARP Request or NS messages, the PE SHOULD use the a) When replying to ARP Request or NS messages, the PE SHOULD use the
Proxy-ARP/ND entry MAC address as MAC SA. This is recommended so Proxy-ARP/ND entry MAC address as MAC SA. This is RECOMMENDED so
that the resolved MAC can be learned in the MAC FIB of potential that the resolved MAC can be learned in the MAC FIB of potential
layer-2 switches sitting between the PE and the CE requesting the layer-2 switches sitting between the PE and the CE requesting the
Address Resolution. Address Resolution.
b) A PE SHOULD NOT reply to a request/solicitation received on the b) A PE SHOULD NOT reply to a request/solicitation received on the
same attachment circuit over which the IP->MAC is learned. In this same attachment circuit over which the IP->MAC is learned. In this
case the requester and the requested IP are assumed to be case the requester and the requested IP are assumed to be
connected to the same layer-2 switch/access network linked to the connected to the same layer-2 switch/access network linked to the
PE's attachment circuit, and therefore the requested IP owner will PE's attachment circuit, and therefore the requested IP owner will
receive the request directly. receive the request directly.
skipping to change at page 13, line 19 skipping to change at page 13, line 19
Proxy-ND and Secure ND [RFC3971] in the same EVI. The 'unicast- Proxy-ND and Secure ND [RFC3971] in the same EVI. The 'unicast-
forward unknown-options' configuration allows the support of new forward unknown-options' configuration allows the support of new
applications using ARP/ND in the EVI while still reducing the applications using ARP/ND in the EVI while still reducing the
flooding at the same time. flooding at the same time.
4.4. Maintenance Sub-Function 4.4. Maintenance Sub-Function
The Proxy-ARP/ND tables SHOULD follow a number of maintenance The Proxy-ARP/ND tables SHOULD follow a number of maintenance
procedures so that the dynamic IP->MAC entries are kept if the owner procedures so that the dynamic IP->MAC entries are kept if the owner
is active and flushed if the owner is no longer in the network. The is active and flushed if the owner is no longer in the network. The
following procedures are recommended: following procedures are RECOMMENDED:
a) Age-time a) Age-time
A dynamic Proxy-ARP/ND entry MUST be flushed out of the table if A dynamic Proxy-ARP/ND entry MUST be flushed out of the table if
the IP->MAC has not been refreshed within a given age-time. The the IP->MAC has not been refreshed within a given age-time. The
entry is refreshed if an ARP or NA message is received for the entry is refreshed if an ARP or NA message is received for the
same IP->MAC entry. The age-time is an administrative option and same IP->MAC entry. The age-time is an administrative option and
its value should be carefully chosen depending on the specific its value should be carefully chosen depending on the specific
use-case: in IXP networks (where the CE routers are fairly static) use-case: in IXP networks (where the CE routers are fairly static)
the age-time may normally be longer than in DC networks (where the age-time may normally be longer than in DC networks (where
mobility is required). mobility is required).
b) Send-refresh option b) Send-refresh option
The PE MAY send periodic refresh messages (ARP/ND "probes") to the The PE MAY send periodic refresh messages (ARP/ND "probes") to the
owners of the dynamic Proxy-ARP/ND entries, so that the entries owners of the dynamic Proxy-ARP/ND entries, so that the entries
can be refreshed before they age out. The owner of the IP->MAC can be refreshed before they age out. The owner of the IP->MAC
entry would reply to the ARP/ND probe and the corresponding entry entry would reply to the ARP/ND probe and the corresponding entry
age-time reset. The periodic send-refresh timer is an age-time reset. The periodic send-refresh timer is an
administrative option and is recommended to be a third of the age- administrative option and is RECOMMENDED to be a third of the age-
time or a half of the age-time in scaled networks. time or a half of the age-time in scaled networks.
An ARP refresh issued by the PE will be an ARP-Request message An ARP refresh issued by the PE will be an ARP-Request message
with the Sender's IP = 0 sent from the PE's MAC SA. If the PE has with the Sender's IP = 0 sent from the PE's MAC SA. If the PE has
an IP address in the subnet, for instance on an IRB interface, an IP address in the subnet, for instance on an IRB interface,
then it MAY use it as a source for the ARP request (instead of then it MAY use it as a source for the ARP request (instead of
Sender's IP = 0). An ND refresh will be a NS message issued from Sender's IP = 0). An ND refresh will be a NS message issued from
the PE's MAC SA and a Link Local Address associated to the PE's the PE's MAC SA and a Link Local Address associated to the PE's
MAC. MAC.
The refresh request messages should be sent only for dynamic The refresh request messages SHOULD be sent only for dynamic
entries and not for static or EVPN-learned entries. Even though entries and not for static or EVPN-learned entries. Even though
the refresh request messages are broadcast or multicast, the PE the refresh request messages are broadcast or multicast, the PE
SHOULD only send the message to the attachment circuit associated SHOULD only send the message to the attachment circuit associated
to the MAC in the IP->MAC entry. to the MAC in the IP->MAC entry.
The age-time and send-refresh options are used in EVPN networks to The age-time and send-refresh options are used in EVPN networks to
avoid unnecessary EVPN RT2 withdrawals: if refresh messages are sent avoid unnecessary EVPN RT2 withdrawals: if refresh messages are sent
before the corresponding BD FIB and Proxy-ARP/ND age-time for a given before the corresponding BD FIB and Proxy-ARP/ND age-time for a given
entry expires, inactive but existing hosts will reply, refreshing the entry expires, inactive but existing hosts will reply, refreshing the
entry and therefore avoiding unnecessary MAC and MAC-IP withdrawals entry and therefore avoiding unnecessary MAC and MAC-IP withdrawals
skipping to change at page 14, line 39 skipping to change at page 14, line 39
for the CEs are all provisioned on the local PE, a given Proxy-ARP/ND for the CEs are all provisioned on the local PE, a given Proxy-ARP/ND
table will only contain static and EVPN-learned entries. In this table will only contain static and EVPN-learned entries. In this
case, the operator may choose to suppress the flooding of ARP/NS/NA case, the operator may choose to suppress the flooding of ARP/NS/NA
to remote PEs completely. to remote PEs completely.
The flooding may also be suppressed completely in IXP networks with The flooding may also be suppressed completely in IXP networks with
dynamic Proxy-ARP/ND entries assuming that all the CEs are directly dynamic Proxy-ARP/ND entries assuming that all the CEs are directly
connected to the PEs and they all advertise their presence with a connected to the PEs and they all advertise their presence with a
GARP/unsolicited-NA when they connect to the network. GARP/unsolicited-NA when they connect to the network.
In networks where fast mobility is expected (DC use-case), it is not In networks where fast mobility is expected (DC use-case), it is NOT
recommended to suppress the flooding of unknown ARP-Requests/NS or RECOMMENDED to suppress the flooding of unknown ARP-Requests/NS or
GARPs/unsolicited-NAs. Unknown ARP-Requests/NS refer to those GARPs/unsolicited-NAs. Unknown ARP-Requests/NS refer to those
ARP-Request/NS messages for which the Proxy-ARP/ND lookups for the ARP-Request/NS messages for which the Proxy-ARP/ND lookups for the
requested IPs do not succeed. requested IPs do not succeed.
In order to give the operator the choice to suppress/allow the In order to give the operator the choice to suppress/allow the
flooding to remote PEs, a PE MAY support administrative options to flooding to remote PEs, a PE MAY support administrative options to
individually suppress/allow the flooding of: individually suppress/allow the flooding of:
o Unknown ARP-Request and NS messages. o Unknown ARP-Request and NS messages.
o GARP and unsolicited-NA messages. o GARP and unsolicited-NA messages.
skipping to change at page 21, line 45 skipping to change at page 21, line 45
[RFC7342] Dunbar, L., Kumari, W., and I. Gashinsky, "Practices for [RFC7342] Dunbar, L., Kumari, W., and I. Gashinsky, "Practices for
Scaling ARP and Neighbor Discovery (ND) in Large Data Centers", Scaling ARP and Neighbor Discovery (ND) in Large Data Centers",
RFC 7342, DOI 10.17487/RFC7342, August 2014, <https://www.rfc- RFC 7342, DOI 10.17487/RFC7342, August 2014, <https://www.rfc-
editor.org/info/rfc7342>. editor.org/info/rfc7342>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971,
March 2005, <https://www.rfc-editor.org/info/rfc3971>. March 2005, <https://www.rfc-editor.org/info/rfc3971>.
[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>.
[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
DOI 10.17487/RFC5227, July 2008, <https://www.rfc- DOI 10.17487/RFC5227, July 2008, <https://www.rfc-
editor.org/info/rfc5227>. editor.org/info/rfc5227>.
[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, <http://www.rfc-editor.org/info/rfc2119>. 1997, <http://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,
<http://www.rfc-editor.org/info/rfc8174>. <http://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[ARP-Sponge] Wessel M. and Sijm N., Universiteit van Amsterdam, [ARP-Sponge] Wessel M. and Sijm N., Universiteit van Amsterdam,
"Effects of IPv4 and IPv6 address resolution on AMS-IX and the ARP "Effects of IPv4 and IPv6 address resolution on AMS-IX and the ARP
Sponge", July 2009. Sponge", July 2009.
[EVPN-ND-FLAGS] Sathappan S., Nagaraj K. and Rabadan J., "Propagation [EVPN-ARP-ND-FLAGS] Sathappan S., Nagaraj K. and Rabadan J.,
of IPv6 Neighbor Advertisement Flags in EVPN", draft-ietf-bess-evpn- "Propagation of ARP/ND Flags in EVPN", draft-ietf-bess-evpn-na-flags-
na-flags-02, Work in Progress, October 2018. 04, Work in Progress, July 2019.
[Euro-IX BCP] https://www.euro-ix.net/pages/28/1/bcp_ixp.html [Euro-IX BCP] https://www.euro-ix.net/pages/28/1/bcp_ixp.html
10. Acknowledgments 10. Acknowledgments
The authors want to thank Ranganathan Boovaraghavan, Sriram The authors want to thank Ranganathan Boovaraghavan, Sriram
Venkateswaran, Manish Krishnan, Seshagiri Venugopal, Tony Przygienda, Venkateswaran, Manish Krishnan, Seshagiri Venugopal, Tony Przygienda,
Robert Raszuk and Iftekhar Hussain for their review and Robert Raszuk and Iftekhar Hussain for their review and
contributions. Thank you to Oliver Knapp as well, for his detailed contributions. Thank you to Oliver Knapp as well, for his detailed
review. review.
11. Contributors
In addition to the authors listed on the front page, the following
co-authors have also contributed to this document:
Wim Henderickx
Nokia
Daniel Melzer
DE-CIX Management GmbH
Erik Nordmark
Zededa
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
Email: senthil.sathappan@nokia.com Email: senthil.sathappan@nokia.com
Kiran Nagaraj Kiran Nagaraj
Nokia Nokia
Email: kiran.nagaraj@nokia.com Email: kiran.nagaraj@nokia.com
Wim Henderickx
Nokia
Email: wim.henderickx@nokia.com
Greg Hankins Greg Hankins
Nokia Nokia
Email: greg.hankins@nokia.com Email: greg.hankins@nokia.com
Thomas King Thomas King
DE-CIX Management GmbH DE-CIX Management GmbH
Lichtstrasse 43i, Cologne 50825, Germany Lichtstrasse 43i, Cologne 50825, Germany
Email: thomas.king@de-cix.net Email: thomas.king@de-cix.net
Daniel Melzer
DE-CIX Management GmbH
Lichtstrasse 43i, Cologne 50825, Germany
Email: daniel.melzer@de-cix.net
Erik Nordmark
Email: nordmark@sonic.net
 End of changes. 21 change blocks. 
33 lines changed or deleted 33 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/