Hi Dale,
Thanks for the review. See below.
On Wed, Jun 28, 2017 at 10:35 PM, Dale Worley <worley(_at_)ariadne(_dot_)com>
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 +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3(_at_)gmail(_dot_)com