[trill] Eric Rescorla's No Objection on draft-ietf-trill-arp-optimization-09: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-trill-arp-optimization-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S 2.

   plane on the edge RBridges, it should be possible to completely
   suppress flooding of ARP/ND messages in a TRILL Campus, When all end-
   station MAC addresses are similarly known, it should be possible to
   suppress unknown unicast flooding by dropping any unknown unicast
   received at an edge RBridge.

Are these "should be possibles" normative? Descriptive?

S 4.
This is a sequence of steps, so it would be nice to preface them with
a list of the steps. It's also odd to have SEND considerations right
in the middle here.


4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP
Please explain what a non-zero IP is and why it's relevant.
This graf also needs an introductory sentence or something before
the bullets.


S 4.4.
   It is not essential that all RBridges use the same strategy for which
   option to select for a particular ARP/ND query. It is up to the
   implementation.

This seems inconsistent with the MUST in arm (b) below, because I
can just take some other arm. It's also kind of surprising to be this
non-prescriptive.


S 8.
   some other location (MAC/VM Mobility) and gets connected to egde-

Nit: edge is mispelled.