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. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art