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

Donald Eastlake <d3e3e3@gmail.com> Thu, 09 November 2017 14:26 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166D9126BF6; Thu, 9 Nov 2017 06:26:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsbciP6oBETW; Thu, 9 Nov 2017 06:26:23 -0800 (PST)
Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1BD124319; Thu, 9 Nov 2017 06:26:23 -0800 (PST)
Received: by mail-ot0-x22b.google.com with SMTP id n74so5405338ota.8; Thu, 09 Nov 2017 06:26:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8a7SedRM3PcDIgHCdrH6qBrEDDqeBnKT9ZjN7M9kd/c=; b=uedmxMkPF4ZHaqYBlkwZaaKLmAcvSGDO++w7f/NqjeVKsZ1p9KZulSePXM+rUHwgOz XXtgJOA5Fqx1ZE3r8gL7fHmUcmPHrU7vcqoXuI5FPD8PPuXf1O2C0LdjULjUpuP0GWv9 1GFes8gebqutAV5JdMBKESIs2iadjX2dh5x0FtmfZgLFox+jattGx0jIB98erZaf1YaL mxOE2H27QV9Tu0Y+ePnNzg7L8r0LUIjwaro0RYK84n5yDQAzKavRNLFGlXIsObI4Z6wG Y3chZMks0zM9plwosahpRIOtuLp4HUBebLJmt9a9zr6qx4HsZc78LpLoZSfezF0M85mU 86EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8a7SedRM3PcDIgHCdrH6qBrEDDqeBnKT9ZjN7M9kd/c=; b=Ybz8tmAfCIPftqxO+0W9/Z3yY33UM7Gs5xgGT5G91QLns8KuT/ChHFuSBNzC7bwvZV Y/voIxDDXdPVP81F1tDgmKks16ga03Wud5SsE9u7QJI4/5HVPsiZSpQcYQestNLgreZi dQ6+WsPbQx9W6jFDLzUXWpAxNsA+YW0z6iK0DMqjEHrooyXmYPORdw0iemKJnV+rE8/1 4XR/RoLHlnB4knF4yuLWW/Wj7gW03mSTm8DaLDUb+WBjxtj+im5wRzTkPukD0a3Dj0UF zb2pMlV9LTN2q40BdE0cOTzT1m84fvYHZrkfJx6EP4JTVL3eQwlXQ0PHq0IQpFQKNEAy leGA==
X-Gm-Message-State: AJaThX5udKfnFfYLv2UdhH4XdrdmarE6SjIcgHQ6z/o5HWvPF/mv3bPW wtxM/DDS1LrsnAc3Sf1zp/kKPiFALX9wR8+se3LxTCqa
X-Google-Smtp-Source: AGs4zMYOalo7w/HJqIlaSe6LlImgqqrSjtz5pmo8W+Xzblb3x8FnhNAyHQXJYuxLINOjcFz+EpSGWgFnh/DUack5YMM=
X-Received: by 10.157.35.11 with SMTP id j11mr404893otb.167.1510237583023; Thu, 09 Nov 2017 06:26:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.73.194 with HTTP; Thu, 9 Nov 2017 06:26:07 -0800 (PST)
In-Reply-To: <151023481007.31307.12258000321227182531.idtracker@ietfa.amsl.com>
References: <151023481007.31307.12258000321227182531.idtracker@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 09 Nov 2017 09:26:07 -0500
Message-ID: <CAF4+nEF6xA+0N5nQ+D2Qs43f+LqCn-2DN7M2sYHka6L_yQ3XoA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-trill-arp-optimization@ietf.org, "trill-chairs@ietf.org" <trill-chairs@ietf.org>, Susan Hares <skh@ndzh.com>, "trill@ietf.org" <trill@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/d2wbIbgcWfSfOcAbRF-5qH-xIBA>
Subject: Re: [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
Precedence: list
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 14:26:25 -0000

Hi Eric,

Thanks for clearing your DISCUSS. See responses below to your
remaining COMMENTs.

On Thu, Nov 9, 2017 at 8:40 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-arp-optimization-09: No Objection
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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?

The following sentence was added earlier in Section 2 to make it clear
that these were not normative:
   "This section is a general discussion of this
   problem and is not intended to be normative."

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

Section 4.3 has been re-named. "non-zero" no longer occurs anywhere in
this document. An introductory paragraph was added 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
>    implementation.
>
> 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
> non-prescriptive.

This is not actually inconsistent. The paragraph at the beginning of
Section 4.4 explains that which lettered "arm" you take is fixed by
the situation; it is an implementation choice which numbered sub-arm
to take under each lettered arm.

> S 8.
>    some other location (MAC/VM Mobility) and gets connected to egde-
>
> Nit: edge is mispelled.

As far as I can see, the misspelling of edge has been fixed in -09.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com