[trill] Genart last call review of draft-ietf-trill-arp-optimization-08

[Dale Worley <[e-mail]>]

Reviewer: Dale Worley
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

Document:  draft-ietf-trill-arp-optimization-08
Reviewer:  Dale R. Worley
Review Date:  2017-06-28
IETF LC End Date:  2017-06-29
IESG Telechat date:  unknown

Summary:

       This draft is basically ready for publication, but has nits
       that should be fixed before publication.

   Abstract

   This document describes mechanisms to optimize the ARP (Address
   Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
   campus.

s/in TRILL campus/in a TRILL campus/

Perhaps summarize what the optimizations are:

   Each edge RBridge maintains a cache of IP/MAC address/Data Label
   bindings that are learned from ARP/ND requests and responses that
   pass through it.  This cache allows it to avoid flooding an ARP/ND
   request by either responding to it directly or by encapsulating it
   and unicasting it to the location where it is in use.

   2 ARP/ND Optimization Requirement and Solution

   (including DHCP or gratuitous ARP_messages).

s/_//

   and should allow an end station to
   detect duplicate IP addresses.

Unless this is a well-known phrase, it would be best if it was clear
whether the end station is detecting that its own IP address is
duplicated, or whether it is detecting that some other station's IP
address is duplicated.

   TRILL already provides an option to disable data-plane learning from
   the source MAC address of end-station frames on a per port basis (see
   Section 5.3 of [RFC6325]).

Given how this section is written, shouldn't this option be considered
an option to *enable* data-plane learning?  And in particular, doesn't
that imply that TRILL already includes a solution to suppress ARP
flooding?

Also, what is the meaning of "learning from the source MAC address"?
It seems like you'd want to specify what the learning is *of*, and
then perhaps what it is learned *from*.

Or is this particular learning of MAC addresses alone, and not of
IP/MAC bindings?  If so, then isn't this feature orthogonal to ARP/ND
optimization?

As a design matter, I'm curious why an RBridge can't learn IP/MAC
bindings by snooping data packets, and only by snooping ARP packets.
I suspect there are good reasons for it, but the naive reader (me) is
left wondering...

   4.1 SEND Considerations

   Secure SEND messages require knowledge of cryptographic keys. Methods
   of communicating such keys to RBridges for use in SEND are beyond the
   scope of this document. Thus, using the optimizations in this
   document, RBridges do not attempt to construct SEND messages and are
   generally transparent to them. RBridges only construct ARP, RARP, or
   insecure ND messages, as appropriate.

This doesn't flow quite correctly.  The second sentence suggests that
there are known mechanisms for distributing keys to RBridges, but that
this document doesn't describe them.  The reader then expects that the
third sentence will say that if RBridges are provisioned with keys in
an environment, they can generate SEND responses.  But instead, the
real meaning of the second sentence seems to be that there are no such
ways of distributing keys to RBridges and therefore they can't
generate SEND responses.  That suggests that the second sentence
should be rephrased:

    There are no methods of communicating such keys to RBridges for
    use in SEND, and thus RBridges cannot construct SEND messages and
    must be generally transparent to them.

Or perhaps "SEND forbids communicating such keys to RBridges, and
thus...".

   4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP 

What is "non-zero IP"?  Is this the case discussed in section 4.4 item
(d)?  (If so, it also includes "a Neighbor Solicitation for DAD
... which has the unspecified source address".)  Perhaps the property
being described is "Get Sender's IP/MAC Mapping Information from
Non-Address Probe ARP/ND Queries".

   4.4 Determine How to Reply to ARP/ND

   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.

It appears that the division between options (a), (b), (c), and (d)
are fixed by the draft, so this statement is rather confusing.  Also,
"It is up to the implementation." is a bit awkward.  Perhaps:

   Within each item, it is an implementation decision which strategies
   to use for any particular ARP/ND query falling under that item.

--

     Because the edge RBridge might not have an IPv6 address, the
     source IP address for such an ND response MUST be that of the
     target end station.

Wouldn't the source IP address for such an ARP response also be that
of the target end station, given that it is a simulated ARP response
from the target end station?  That is, why is this MUST specific to
IPv6?

     b.3. Drop the message if the directory mechanism is used and you
     know there should be no response (query based on an non-existent IP
     address for example).

It would be better to phrase this:

     b.3. Drop the message if the directory server gives authoritative
     information that the IP address is non-existent.

   4.5 Determine How to Handle the ARP/ND Response

   the target's egress RBridge R2 as discussed in subsection 3.2 item a)

Really, it's subsection 3.2 item a.2.

   or to flood the request as per [RFC6325]

Isn't this item a.5?

   When/if the target responds, 

Probably better as "If and when the target responds,".

   5 Handling RARP (Reverse Address Resolution Protocol) Messages

The title of section 5 starts "Handling" whereas the titles of
sections 6 and 7 start "Handling of".  It's probably worth making the
three consistent.

   Its use is similar to

Shouldn't this be "Its processing is similar to"

   Normally, it is used to
   look up a MAC address to find the corresponding IP address.

Doesn't this duplicate the third sentence of this paragraph?

   7 Handling of Duplicate IP Addresses

   Duplicate IP addresses can be detected when an existing active
   IP1/MAC1 mapping gets modified.

Should "IP1/MAC1" be "IP/MAC"?  Neither "IP1" nor "MAC1" is used
elsewhere in the document.

   Also an edge RBridge may send a query
   to the former owner of IP called a DAD-query (Duplicate Address
   Detection query).

This is a bit ambiguous -- is it the query or the former owner that is
called a DAD-query?  Better "may send a query called a DAD-query (...)
to the former owner of the IP".

However the following discussion does not specify how the DAD-query is
addressed to the "former owner", and so doesn't specify if the former
owner is defined by the MAC address previously associated with the IP
address or what.  The protocol logic seems to require that the
destination MAC is the one previously associated with the IP address
and the queried-for IP must be the IP in question.  This should be
spelled out, since the source addressing is specified.

   In the case where the former owner replies, a Duplicate Address has
   been detected. In this case the querying RBridge SHOULD log the
   duplicate so that the network administrator can take appropriate
   action.

What action should the querying RBridge take in regard to its cache?

   9 Security Considerations

s/as provide in/as provided in/ (two instances)

   12.1 Normative References

   [DirMech] Dunbar, L., Eastlake 3rd, D., Perlman, R., I. Gashinsky.
              and Li Y., TRILL: Edge Directory Assist Mechanisms",
              draft-ietf-trill-directory-assist-mechanisms, work in
              progress.

There are unbalanced double-quotes here.