Skip to main content

Last Call Review of draft-ietf-bess-evpn-proxy-arp-nd-04

Request Review of draft-ietf-bess-evpn-proxy-arp-nd-04
Requested revision 04 (document currently at 16)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2018-09-14
Requested 2018-08-15
Requested by Matthew Bocci
Authors Jorge Rabadan , Senthil Sathappan , Kiran Nagaraj , Greg Hankins , Thomas King
I-D last updated 2018-08-30
Completed reviews Opsdir Last Call review of -04 by Joe Clarke (diff)
Rtgdir Last Call review of -09 by Ravi Singh (diff)
Secdir Last Call review of -09 by Russ Housley (diff)
Genart Last Call review of -09 by Russ Housley (diff)
Intdir Telechat review of -11 by Jean-Michel Combes (diff)
Secdir Telechat review of -11 by Russ Housley (diff)
This document is currently in WG last call. It potentially impacts the way Proxy-ARP/ND is used in networks where EVPN is deployed and so needs wider review.
Assignment Reviewer Joe Clarke
State Completed
Request Last Call review on draft-ietf-bess-evpn-proxy-arp-nd by Ops Directorate Assigned
Reviewed revision 04 (document currently at 16)
Result Has issues
Completed 2018-08-30
I have been assigned to do an OPS DIR review of draft-ietf-bess-proxy-arp-nd. 
This document describes how the proxy ARP/ND functions of EVPN can be used to
mitigate the impact of address resolution in large broadcast domains.  While
the text does support the abstract and describes how such proxy functions can
help prevent flooding of broadcast traffic into the EVPNs, I found something
noticeably missing from an operational point of view.  This was especially
apparent since the concept of an ARP-Sponge was also discussed.  That is, one
of the big operational headaches of a large broadcast domain is with negative
ARP/ND (especially ARP).  We actually see this in the IETF conference networks
due to internet backscatter (we might be considered a DC in this regard). 
While the proxy functions can mitigate the positive address resolution, they
will not help with negative caching.  I feel that should be discussed, at least
in the security recommendations, assuming there is not a proposal for adding
capabilities to the EVPN proxy functions to further mitigate this.

An overall nit is that you seem to mix capitalization of various terms like
Ethernet, Proxy-ARP, Layer-2, etc.  It would be good to normalize these for
easier reading.

Other comments and nits on a per-section basis are found below.

Section 2.1:

In general, I found this section lacking when compared with the IXP section
below it.  You describe that large DCs may have a problem with broadcasts, but
that is a known quantity.  What I was expecting is to see more on how this
document is applicable to that scenario like you did with the subsequent IXP


Section 4

"When CE3 sends an ARP Request asking for IP1..."

Technically, CE3 is asking for the MAC address of IP1.


Section 4.2

s/potential Layer-2 switches seating/potential Layer-2 switches sitting/


Section 4.4

You say that a dynamic Proxy-ARP/ND entry SHOULD be flushed.  It MUST be
flushed if the age-time expires.  I think this should be restated applying the
SHOULD to whether or not an age-time is implemented.  IMHO, if an age-time is
implemented, keeping an entry in the table after it has aged out is incorrect
behavior.  An implementation MUST NOT do that.


Section 6.5

LAG is not listed in your glossary of abbreviations.


Section 7

Typically the conventions section is located at the top of a document, after
the abstract.