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

[Donald Eastlake <[e-mail]>]

Hi Dale,

Thanks for the review. See below.

On Wed, Jun 28, 2017 at 10:35 PM, Dale Worley <[e-mail]> wrote:
> 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/

OK.

> 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.

Wording along those lines sounds like a good addition.

>    2 ARP/ND Optimization Requirement and Solution
>
>    (including DHCP or gratuitous ARP_messages).
>
> s/_//

I think the underscore should be replaced by a space rather than the
null string.

>    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.

This is talking about the end station doing normal DAD by probing for
its own IP address.
"detect duplicate IP addresses" -> "detect duplication of its IP address".

>    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?

By default RBridges learn the source MAC addresses of the Ethernet
frames they receive from attached end stations in a way similar to
such data plane learning by bridges. A change in that default, to not
learn such MAC addresses requires optional configuration. I don't
think just learning MAC addresses is useful for the types of ARP
flooding suppression talked about in this document.

> 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 per RFC 6325, RBridge default to data plane learning of MAC
addresses but not IP addresses. Although TRILL has ways of arbitrating
between conflicting addressing information learned through different
paths, it may be useful to disable data plane MAC address learning
when a directory is being used or the like.

> 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...

You can get miscellaneous data packets at line speed so MAC address
learning is frequently implemented in hardware. While there is no
reason you couldn't do that for IP addresses, if you don't want to
require hardware changes from that in most existing implementations,
you would learn from ARP/ND in software which is generally practical
as they are not normally received that frequently.

>    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.

I disagree. Saying "X is beyond the scope of this document" means what
it says: that the topic is not further touched on in this document. I
do not think it implies that techniques to do X do or do not exist.

>                                                                  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:

I disagree. I don't think the typical reader would have such an
expectation. Even if there were standardized or deployed ways to put
such keys on edge RBridges, having said they were out of scope, I
would expect that further mechanisms built on such keys would also be
out of scope and not covered by the document.

>     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.

The existing wording goes as far as I think it should. I don't see any
reason to make it stronger and more restrictive.

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

I don't think SEND says anything about communicating such keys and it
seems like a bad idea for a TRILL document to be putting words in
SEND's mouth. If there is such a provision in the SEND specification
could you point it out to me?

>    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".

This is section is talking about getting and handling the IP/MAC
mapping information for a local end station by an edge RBridge. An
ARP/ND from such a local end station might show a zero source IP
address if the end station does not have one or is probing for
duplicates.

Perhaps the title for the Section should be something like

   4.3 Extracting Local End Station IP/MAC Mapping Information

and a new first paragraph could be added something like

   Edge RBridges extract and use information about the correspondence
between local end station IP and MAC addresses from the ARP/ND
messages those end stations send as described below. An apparent zero
source IP address means that the end station is probing for duplicate
IP addresses and messages with such a zero source IP address are not
used for the extraction of IP/MAC address mapping information.

>    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.

OK except "strategy" should be singular.

> --
>
>      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?

ARP messages are not IP messages. They are link local layer 2
messages. Perhaps it could suggest that the source MAC address for an
ARP be that of the end station that would normally have sent the ARP
but all the information needed is inside the ARP message so there is
no need for an ARP implementation to look at any outer addressing of
an ARP message, such as MAC addresses on an Ethernet link, and I do
not think such implementations look at such outer addresses.
Furthermore, when this draft was previously considered by the IESG, we
were asked to specify the source IPv6 addresses for ND messages but
nothing along those lines was said about ARP messages.

Item a.5: "/ND/SEND" -> "ARP/ND/SEND"

>      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.

OK.

>    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.

Yes.

>    or to flood the request as per [RFC6325]
>
> Isn't this item a.5?

Yes.

>    When/if the target responds,
>
> Probably better as "If and when the target responds,".

OK.

>    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.

OK.

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

OK.

>    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?

Yes, that sentence should probably be deleted.

>    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.

OK.

>    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".

OK.

> 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.

OK.

>    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?

There is no inherent right answer that TRILL can specify when you have
duplicate IP assignments. (If there is a directory controlled by an
omniscient orchestration system, then the directory should be assumed
to be correct and conflicting IP assignments should be ignored.)

>    9 Security Considerations
>
> s/as provide in/as provided in/ (two instances)

OK.

>    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.

That draft has issue as RFC 8171 so the reference should be updated.

Thanks again for the review. Although I think a few of your comments
are off the mark, most of them will result in improved wording and
clarity.

Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]