Re: [RTG-DIR] Routing Directorate Review of TRILL ARP Optimization

Eric Gray <> Fri, 05 June 2015 18:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BAC4C1A1A58 for <>; Fri, 5 Jun 2015 11:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LD_F05K9W1fb for <>; Fri, 5 Jun 2015 11:09:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B6921A03A1 for <>; Fri, 5 Jun 2015 11:09:28 -0700 (PDT)
X-AuditID: c6180641-f79086d000001909-0b-5571803230c9
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id AB.CF.06409.23081755; Fri, 5 Jun 2015 12:55:46 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Fri, 5 Jun 2015 14:09:26 -0400
From: Eric Gray <>
To: Jon Hudson <>, "" <>
Thread-Topic: Routing Directorate Review of TRILL ARP Optimization
Thread-Index: AQHQl7cCpuTA5XXkIkeXfIK0RTeKOp2OPsGAgA/jzAA=
Date: Fri, 05 Jun 2015 18:09:26 +0000
Message-ID: <>
References: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF632D52ABAeusaamb107erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXSPt65RQ2Gowdnv+hafW8+zW1w4tJDJ YsGap+wOzB47Z91l91iy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4MlYfns1YsOAWY8X9XsUG xgNXGLsYOTgkBEwkJqzT7GLkBDLFJC7cW88GYgsJHGWUeDjds4uRC8hexiixasJuJpAEm4CG xLE7axlBEiICExglHi38ywIyiFlAU2LtZS6QGmEBR4n+3tssILaIgJPE4o/H2CFsK4nT8y8z gtgsAioSN3tPMYPYvAK+Eo3P9zBDLA6UmLJ4HVgvI9BB30+tAdvLLCAucevJfCaIQwUkluw5 zwxhi0q8fPyPFcJWlNjXP50doj5f4uHJmSwQ8wUlTs58wjKBUWQWklGzkJTNQlI2C+qb9bv0 IUoUJaZ0P2SHsDUkWufMZUcWX8DIvoqRo7Q4tSw33chwEyMwno5JsDnuYFzwyfIQowAHoxIP 7wKmwlAh1sSy4srcQ4zSHCxK4rzSfnmhQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjnyFoG fclnPuAcN01h8kau7+F/smrdOiSv5sYqiocpGU74qMdiMi9p5ZGyrpW33/A9C7DPv69zvzTY 9PWsGR08TDH+vok/OpNXm/yZ/9b33AVv0aPd/sc1uYXSqzSuLOE//J3zVM7uuX176rcGrZ5x aK3p9e95BnYB91quOz63zQuKvSPG4qLEUpyRaKjFXFScCABs/XukiAIAAA==
Archived-At: <>
Cc: "" <>
Subject: Re: [RTG-DIR] Routing Directorate Review of TRILL ARP Optimization
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Jun 2015 18:09:31 -0000


I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-trill-arp-optimization

Reviewer: Eric Gray

Review Date: 5 June, 2015

IETF LC End Date: unknown

Intended Status: Standards Track


I have some minor concerns about this document that I think should be resolved before publication.


•Generally, I found this draft to be very well written and easily understandable.

• I had some difficulty in drawing a line between minor comments and NITs in a

    few cases.  I tried to treat comments that were about typos, spelling errors or

    grammar as NITs and other cases where wording choices were ambiguous, or

    potentially misleading as minor comments.  Hopefully the intent of each of my

    comments is clear.

Major Issues:

•No major issues found.

Minor Issues:

• I have some difficulty in parsing the second sentence of the first paragraph

   under section 1.1 (Terminology).  What does “listed below for convenience

    with the following along with some additions” mean?

• The last sentence in the definition of “Campus” adds no value and should be

    removed. The English meaning of Campus includes usages that are not limited

    to schools (which is what I assume you mean in using the term “academic” – as

    opposed to differentiation from “practical” or “commercial”).  For example, a

    corporation or partnership may have more than one campus.

• MAC is an acronym for Media Access Control, which is a link-layer function that

    has an address; “MAC” and “MAC Address” are not synonymous.  You could

    resolve this issue by either removing “address” or putting it in parentheses.

• The definition for RBridge is inadequate as is, because it uses the undefined

    phrase “Routing Bridge.”  This phrase is ambiguous generally (though likely not

    so much in this context) because it could be taken to mean a device that is a

    Bridge with some subset of IP routing capabilities (which isn’t what you mean)

    to differentiate such a device from a Bridging Router (a common capability in

    many – if not most – routers).

• In Bullet “a.1” in section 3.2 (Determine How to Reply to ARP/ND), “believed”

    is the wrong term.  RBridges – like any other devices – are incapable of having

    beliefs.  Either it “knows” the mapping information required to construct a

    response (through whatever means), or it does not.  As a side note, it might be

    philosophically interesting to define what “belief” means for a device.  ☺

• In the next-to-last paragraph of section 3.2, I am pretty sure you want to say

   that encryption would (as opposed to might) prevent local reply.  That is what

   signing responses is precisely intended to prevent.

• In section 4, why are the quoted terms “hardware” and “protocol” used?  As

    noted/implied in NITs below, there are many kinds of “hardware” addresses

    and many possible meaning for “protocol” address.  If these are used as they

    are the specific terms used for message content fields, perhaps it would be

    less ambiguous to put IP in parentheses (after “protocol”) and MAC (after


• In section 5 (Security Considerations), the parenthesized fourth paragraph

    should be removed from parentheses and made a separate paragraph.  The

    potential for use of authentication methods to mitigate risk is an important

    things for a security considerations section to highlight.


• Mostly out of curiosity, why define alternative term “TRILL switch” instead of

    simply using one term consistently?  You could simply define an RBridge as a

    device implementing the TRILL protocol and use the term RBridge consistently.

    This approach solves two problems.

• In the definition of the acronym “ND”, “Discoery” should be “Discovery.”

• The word “traditionally” in the first line of section 2 (IP/MAC Address Mappings),

    and “correspondence” in the second line are poor choices.  In the first case, we

    can have no idea what “traditionally” means because there is no “tradition” for

    implementing RBridges.  In the second case, “correspondence” is an ambiguous

    term that is not quite correct in any case.  Also “remote host” should be “remote

    end station” as it is an Ethernet end station that may or may not be a host (it may

    be a router, for example). I recommend rephrasing the entire first sentence as

    “An RBridge (as defined in RFC 6325 and RFC 7172) learns MAC Address and Data

    Label (VLAN or FGL) to nickname mapping information from TRILL data frames it

    receives.”  There has never been anything to prevent an RBridge implementation

    from learning anything that an RBridge implementation might be configured to

    look at.

• In the second paragraph of section 2, “local hosts” should be “end stations.”

• In the third paragraph of section 2 “examples given above shows” should be

   “examples given above show.”

• In the second and third bullets of the second paragraph in section 3 (Handling

    ARP/ND Messages), neither “protocol” nor “hardware” are specific enough.  I

    recommend changing the bullets to read “… sender IP/MAC address …” in both


• In section 3.3 “R2 should initiates” should be “R2 should initiate.”