Re: [RTG-DIR] Rtgdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-09

["Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>]

Hi Ravi,

Thank you for the review. We submitted rev 10.
Please see my comments below.

Thanks.
Jorge

From: Ravi Singh via Datatracker <[e-mail]>
Date: Tuesday, December 22, 2020 at 12:04 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Rtgdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-09
Reviewer: Ravi Singh
Review result: Has Nits

Hello,

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
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

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)

Summary:

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

Comments:

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.
[jorge] changed the abstract as suggested by Russ.


Major Issues: none found.

Minor Issues: none found.

Nits:
1. Figure 1: please show which device owns IP3, for more clarity.
[jorge] done. Thanks.


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?
[jorge] the default values are consistent with the mac duplication default values in RFC7432. The latter controls how fast a mac is considered as duplicate (by default), while in this document the number of moves and window values defines how fast an ip is considered as duplicate (by default). We think it is a good practice to have the same default values to detect duplicate macs and duplicate ips, and since the values are configurable, it should be fine for the operator to customize it to their specific use-case. Hope it is ok – these values are the default ones in some implementations following this document.

        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:"
[jorge] changed, thanks.


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.
[jorge] the draft was informational for quite a few versions. We only changed it to standards-track based on the reasoning of the AD who told us that, since the document is making explicit the RFC7432 procedures for proxy-arp/nd and updates 7432 in that respect, it should become standards-track. We, authors, see the AD’s point but have no issues going either way.


Best regards
Ravi