Last Call Review of draft-ietf-trill-arp-optimization-08

Request Review of draft-ietf-trill-arp-optimization
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-06-29
Requested 2017-06-15
Authors Li Yizhou, Donald Eastlake, Linda Dunbar, Radia Perlman, Mohammed Umair
Draft last updated 2017-07-05
Completed reviews Rtgdir Early review of -00 by Eric Gray (diff)
Rtgdir Early review of -05 by Geoff Huston (diff)
Genart Last Call review of -08 by Dale Worley (diff)
Opsdir Last Call review of -08 by Mahesh Jethanandani (diff)
Secdir Last Call review of -08 by Tina Tsou (diff)
Assignment Reviewer Mahesh Jethanandani
State Completed
Review review-ietf-trill-arp-optimization-08-opsdir-lc-jethanandani-2017-07-05
Reviewed rev. 08 (document currently at 09)
Review result Has Nits
Review completed: 2017-07-05


I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Document reviewed:  draft-ietf-trill-arp-optimization-08

Summary: Ready with Nits

Document Status: Standard Track

General Comments: The abstract of the document says that the draft tries “To reduce the burden on a TRILL campus caused by these multi-destination messages, RBridges MAY implement an "optimized ARP/ND response", as specified herein, when the target's location is known by the ingress RBridge or can be obtained from a directory. This avoids ARP/ND query and answer flooding.” Implementation of this draft will impact the operations of the network. As such careful consideration should be placed on operational and management impact of the draft.

The following comments look at the document both from an operational perspective as well as a management perspective. 

Operational Considerations:

Operational considerations include installation and initial setup, migration path, requirements on other protocols, impact on network operations and verification of correct operation.

From an impact on network operations perspective, this draft proposes to reduce the traffic in the network by preventing a network wide broadcast and multicast of messages. As such it should reduce the impact on the network, when operating correctly. In the worst case, that it is not operating or operating incorrectly, these network broadcast and multicast messages will “leak” into the broader network, where they will be treated just as they are in todays network. For this reason, a migration path may not be required, or existing protocols modified to deal with the change.

From a verification of correct operations, it is not clear how one determines that the RBridge is operating correctly beyond observing individual ARP/ND messages. Does it keep track of ARP/ND messages it has intercepted and responded to on the local network, which would have escaped to the broader network? Keeping track of statistics will allow for tracking the operation of what is defined in the draft.

Management Considerations:

Management considerations include interoperability, fault management, configuration management, accounting, performance and security.

From a configuration management perspective, it is not clear how the configuration of the RBridge is realized. For example, per the draft, RBridge might not verify an IP address if the network manager's policy is to have the network behave, for each Data Label, as if it were a single link and just believe an ARP/ND it receives. If such a configuration is desired, this or an accompanying document needs to define the manageability aspect of RBridge, preferably in the form of a YANG model.

From a accounting perspective, For example, in the draft, RBridge could for generic ARP/ND request seeking the MAC address corresponding to an IP address, if the edge RBridge knows the IP address and corresponding MAC, behavior is as in item (a), otherwise behavior is as in item (b). Behavior for gratuitous ARP and ND Unsolicited Neighbor Advertisements [RFC4861] is given in item (c). And item (d) covers handling of Address Probe ARP Query. Are there specific statistics being maintained for each of these options? Keeping track of individual options allows for capacity management and planning.

A run of idnits revealed a few warnings:

Miscellaneous warnings:

  == Line 99 has weird spacing: '...enience  along...'

  -- The document date (April 17, 2017) is 79 days in the past.  Is this

  Checking references for intended status: Proposed Standard

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'IA-draft' is mentioned on line 390, but not defined

  == Unused Reference: 'RFC7356' is defined on line 540, but no explicit
     reference was found in the text

  == Outdated reference: draft-ietf-trill-directory-assist-mechanisms has
     been published as RFC 8171

     Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.