[trill] Eric Rescorla's No Objection on draft-ietf-trill-arp-optimization-09: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Thu, 09 November 2017 13:40 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21ABE1200F1; Thu, 9 Nov 2017 05:40:10 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-trill-arp-optimization@ietf.org, trill-chairs@ietf.org, skh@ndzh.com, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.65.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151023481007.31307.12258000321227182531.idtracker@ietfa.amsl.com>
Date: Thu, 09 Nov 2017 05:40:10 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/ofCQIk436SgYBGOVlP2xC8stbiE>
Subject: [trill] Eric Rescorla's No Objection on draft-ietf-trill-arp-optimization-09: (with COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Nov 2017 13:40:10 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-trill-arp-optimization-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


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.