Last Call Review of draft-ietf-bmwg-evpntest-08
review-ietf-bmwg-evpntest-08-rtgdir-lc-halpern-2021-06-16-00

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-name-version.txt
Reviewer: your-name
Review Date: date
IETF LC End Date: date-if-known
Intended Status: copy-from-I-D

Summary:
I have some minor concerns about this document that I think should be resolved
before publication.

Major Comments: N/A

Minor Comments:
    Reading section 3.1 on the rate for learning addresses, I am left guessing
    how the procedure is to be performed.  The text references RFC 2889 section
    5.8, but only for the meaning for the terms.  The test procedure is clearly
    different since that test relies on observing flooding.  As best I can
    guess, the test assumes that there is an observable (Netconf ? YANG ?)
    variable that reports how many local MAC addresses the device under test
    has learned.  It would be good to be more explicit about that, if possible
    pointing to the YANG module that defines the parameter to be observed.
  A similar clarification would be helpful on section 3.2 (on control plane MAC
  learning). It probably would be helpful if sections 3.3 and 3.4 then
  referenced sections 3.1 and 3.2 respectively for what is being observed. This
  probably applies to section 4 as well.  If the same variables are to be used,
  then a simple reference to the earlier description would seem to suffice.

  I believe that section 3.8 on high availability is intended to cause a switch
  of traffic path from DUT to MHPE2.   However, the text in that section never
  refers to MHPE 2.  It refers to switch of routing processor.  It is possible
  that this is intended to be a redundancy test within DUT.  If so, it would
  help to be more explicit, since as far as I know we do not standardize that
  behavior.

I am left puzzled as to the need for MHPE2 in these tests.  I assume there is
some obvious and simple reason for including it that I missed.  Could you add
an explanation?

Nits:
    At the end of section 2, the text reads "The X is used as variable..." 
    Could you change that to "The X below is used as a variable ..."?  I spent
    some time looking backwards for the X.

  The equation at the end of section 3.9 (ARD / ND scaling) is somewhat
  misleading.  It uses the same v1, v2, ..vn in successive lines to implicitly
  refer to the IPv4 measurements and the IPv6 measurements.  It would be good
  to name these separately, as obviously the same calculation can not produce
  two different results.