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

Request Review of draft-ietf-bess-evpn-proxy-arp-nd
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2020-12-22
Requested 2020-12-01
Requested by Martin Vigoureux
Authors Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Greg Hankins, Thomas King
Draft last updated 2020-12-22
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)
Assignment Reviewer Ravi Singh 
State Completed
Review review-ietf-bess-evpn-proxy-arp-nd-09-rtgdir-lc-singh-2020-12-22
Posted at
Reviewed rev. 09 (document currently at 11)
Review result Has Nits
Review completed: 2020-12-22



I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ‚Äč

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-bess-evpn-proxy-arp-nd
Reviewer: Ravi Singh
Review Date: 21 Dec 2020
Intended Status: Standards track (as listed on the draft)


This document is basically ready for publication, but has nits that should be considered prior to publication.


The draft is generally well written and easy to understand.
It basically is a description to explain how ARP, ND, EVPN should work together to reduce forwarding of ARP queries and/or NS messages, in an EVPN deployment, by the use of gratuitous ARP/ND.
The abstract, though, could be made more direct by stating as such.

Major Issues: none found.

Minor Issues: none found.

1. Figure 1: please show which device owns IP3, for more clarity.

2. 	Section 4.6 (a):
        a. "       IP moves before the timer expires (default value of N=5), it
       concludes that a duplicate IP situation has occurred.  An IP move". It would be nice to elaborate on why the default value of "5" is recommended. Why not 1? Too much thrashing? However, for the cases where there is no thrashing, having a value of 5 as default slows the DAD procedure. Any recommendation on how to address that?
        b. 	Minor typo: "       owner and spoofer keep replying to the CONFIRM message, the PE
       will detect the duplicate IP within the M timer:" ->
		"      owner and spoofer keep replying to the CONFIRM message, the PE
       will detect the duplicate IP within the M-second timer:"

3. Biggest nit: the draft does not really specify any new messaging formats or any new fields. It is basically saying how the existing ARP, ND, EVPN messaging/machinery (should) work together to achieve flooding-minimization of ARP/ND queries in EVPN. Given the foregoing, it is not clear to me if the draft really should be considered "standards track" instead of "informational". The chairs are requested to evaluate that.

Best regards