TRILL: ARP/ND Optimization

Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.

(Jari Arkko) Discuss

Discuss (2016-07-07 for -06)
Section 3.2 discusses several options for obtaining an answer to a ND query. The section also mentions SEND, which prevents spoofing of results by the bridge itself. I believe it would be useful though to make a clearer recommendation on what to do with regards to the different options on obtaining an answer. Some of them are compatible with SEND, some of them are not. Also, how does one know SEND is being used?

Perhaps the document could specify a configurable mode where SEND is assumed to be in use and then you could not use the options that make this problematic. Or, perhaps better, if a node has been observed as using send, then use the correct option for that node.

Eric Rescorla Discuss

Discuss (2017-07-05 for -08)
It's not clear to me how the security properties of this mechanism
compare to existing TRILL. The text says:

   Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can be
   easily forged. Therefore the learning of MAC/IP addresses by RBridges
   from ARP/ND should not be considered as reliable. See Section 4.1 for
   SEND Considerations.

"not considered as reliable" seems suboptimal. You need to cover how
this mechanism compares to the non-use of this mechanism.

This document seems very sketchy on what you do when you get duplicate

   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

How does logging solve the problem? What do you reply to ARPs with
and/or propagate to other nodes? Do you tell the originator of the
advertisement you have a duplicate?

   When a newly connected end-station exchanges messages with a DHCP
   [RFC2131] server an edge RBridge should snoop them (mainly the
   DHCPAck message) and store IP/MAC mapping information in its ARP/ND
   cache and should also send the information out through the TRILL
   control plane using ESADI.

What happens if the attacker sets up a fake DHCP server and pretends
to assign addresses to himself? It seems like maybe that's the same
as fake ARPs but maybe not.

In general, the security considerations need a complete threat
analysis per 3552.
Comment (2017-07-05 for -08)
S 2.

   plane on the edge RBridges, it should be possible to completely
   suppress flooding of ARP/ND messages in a TRILL Campus, When all end-
   station MAC addresses are similarly known, it should be possible to
   suppress unknown unicast flooding by dropping any unknown unicast
   received at an edge RBridge.

Are these "should be possibles" normative? Descriptive?

S 4.
This is a sequence of steps, so it would be nice to preface them with
a list of the steps. It's also odd to have SEND considerations right
in the middle here.

4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP 
Please explain what a non-zero IP is and why it's relevant.
This graf also needs an introductory sentence or something before
the bullets.

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

This seems inconsistent with the MUST in arm (b) below, because I
can just take some other arm. It's also kind of surprising to be this

S 8.
   some other location (MAC/VM Mobility) and gets connected to egde-

Nit: edge is mispelled.

Alia Atlas Yes

Deborah Brungard No Objection

Ben Campbell No Objection

Benoit Claise No Objection

Comment (2017-07-06 for -08)
- Can you clarify on which device type you need to enable the following option:

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


     1) IP address - indicated protocol address that is normally an IPv4
     address in ARP or an IPv6 address in ND.

"normally"?  I've seen the term "Non-zero IP" later on in the draft

Below is Mahesh's OPS DIR review

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

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.

Alissa Cooper No Objection

Comment (2016-07-06 for -06)
Looking forward to resolution of others' DISCUSS and COMMENTs.

Spencer Dawkins No Objection

Comment (2016-07-06 for -06)
I agree with Suresh's Discuss.

(Stephen Farrell) No Objection

Comment (2016-07-06 for -06)
3.2, 2nd last para: don't you need to say to never fake
SEND responses? saying "prevent local reply" seems unclear
to me, and a MUST NOT would seem called for.  I guess
Suresh's discuss covers that though, so just to note I agree
with him on that.

(Joel Jaeggli) No Objection

Comment (2016-07-07 for -06)
SEND is kinda nonsense,nobody is really going to use it.

Suresh Krishnan (was Discuss) No Objection

Comment (2017-07-04 for -08)
Thanks for addressing my DISCUSS points.

Mirja Kühlewind No Objection

Terry Manderson No Objection

Alexey Melnikov No Objection

Kathleen Moriarty No Objection

Comment (2016-07-06 for -06)
I agree with Stephen and Suresh.

Alvaro Retana (was Discuss) No Objection

Comment (2017-07-03 for -08)
[Thanks for addressing my DISCUSS.]

Warren Kumari No Record

Adam Roach No Record