Re: [trill] draft-ietf-trill-directory-assist-mechanism-10.txt

Donald Eastlake <d3e3e3@gmail.com> Thu, 12 January 2017 18:23 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 AD959128AB0; Thu, 12 Jan 2017 10:23:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 t9hyYOosLN4X; Thu, 12 Jan 2017 10:23:56 -0800 (PST)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 AE8B3129410; Thu, 12 Jan 2017 10:23:56 -0800 (PST)
Received: by mail-it0-x22e.google.com with SMTP id r185so19719380ita.0; Thu, 12 Jan 2017 10:23:56 -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:content-transfer-encoding; bh=WXRGBrOPYPCn3C9Y/ddxWPk7vQHrriTmmBtYUPaUR8c=; b=HonnU5Eh8NBnnI5aXMiXQCBOYwegMzMOWZ1vs8y4XTiyZmhw4PAtqVdUWJ/ei+TSql +6/mseDN3Bd/nvIP7a3HnXiTvPD5g/eKZph1j/H4mcau+qbbMcgHnClAn+MDR8OoFciB 5paCdl7nKmG/nb3Cpuh/fl3U+/YYUoAz/XMGzMGnm8GksQQiTl07l79UtMPshMlN2bxY sIgrwcQ8JGHVHQzsRXvZCIsBfhn0y2nc408F8kYLWcSL8mQhaVuUehXb/1Dg2LnPIhrO n41aMahUkWh1kDSvhy6bwAleb9EdgHtnwY4a0H3XgT+bn5Opu8ESDljSIQma7gkgV2Cm /24Q==
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:content-transfer-encoding; bh=WXRGBrOPYPCn3C9Y/ddxWPk7vQHrriTmmBtYUPaUR8c=; b=txag4cGPExRVG136/kEyiJikKexalZE2TkMxvjVdYtr5pUqQz70UUUnVX2Jc5/0OMP 4WH/U4AsJJt0EaE6WM/oF+jh48US2KJiudMJ9GEwi+wA++blAIRIsWE8tBUyWrGKzb0h 82Bd+5suYLc43B/QUzFPlGdWuvb8X4j8vMf5ZP12elDeZsTgFAkBhUOS21MVEBAnj9oP 0AXgYBEVuQuwgjLyRmMPug/pwZD89nCuQ+VbSOIMtO7HgNh04A2oht/Or1SA9dIrlpdy +eorXIj4NfRrVc6g7GNZlB67n64hAtoHZANY6uVMUPNwWGFlQosY+0DCjSwMUtx7ezDk aF9w==
X-Gm-Message-State: AIkVDXI6t4a6rFC5u2TtY0N2uJ0bxapmkt37C0O7W82W6pMURRDcabd1bOb3cxbN2Oa/pTxqQxqaeP1eTpZlAg==
X-Received: by 10.36.117.148 with SMTP id y142mr5892937itc.14.1484245435804; Thu, 12 Jan 2017 10:23:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.41.72 with HTTP; Thu, 12 Jan 2017 10:23:40 -0800 (PST)
In-Reply-To: <001b01d26a03$3ac96910$b05c3b30$@ndzh.com>
References: <001b01d26a03$3ac96910$b05c3b30$@ndzh.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 12 Jan 2017 13:23:40 -0500
Message-ID: <CAF4+nEEGW_6_7HHMvmS67WLiE3FHaG9z=q6TONUdkrN8-rwS1w@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/UiISkdP6FjBwzw_gX9ZrhFfUK5c>
Cc: Linda Dunbar <linda.dunbar@huawei.com>, draft-ietf-trill-directory-assist-mechanisms@ietf.org, Radia Perlman <radiaperlman@gmail.com>, Liyizhou <liyizhou@huawei.com>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] draft-ietf-trill-directory-assist-mechanism-10.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
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, 12 Jan 2017 18:23:59 -0000

Hi Sue,

Thanks for the review.

On Sun, Jan 8, 2017 at 6:02 PM, Susan Hares <shares@ndzh.com>; wrote:
> Donald, Yizhou, Linda, and Radia:
>
> Thank you for your work on draft-ietf-trill-directory-assist-mechanisms.
> Each draft improves the readability and nails down some of the potential
> edge cases.   I believe we are nearing the end of this journey toward IESG
> approval. I am joining with you on this journey by doing a shepherd review
> at the end of IETF LC.
>
>
> Status: Ready to publication, with some editorial nits you should consider
>
>
>
> Here’s my editorial nits on the latest version.   Please address #2 – that
> deals with the “SEND” functionality and #6
>
>
> #1, p. 5 paragraph 1, list item 3.   – simple spelling error
>
> Old:/MAC addresses “nomrally” /
> New: /MAC Addresses normally/

OK.

> #2. p. 17-22 – section 3
>
> #2.a Overall – I think you need to include SEND messages in this Query
> messages.

OK.

> #2.b p17, section 3.0 paragraph 5  specific text change
>
> Old:/The requests to Pull Directory servers are typically derived from
> ingressed ARP [RFC826], ND [RFC4861],  RARP [RFC903], or
> data frames with unknown unicast destination MAC addresses, intercepted by
> an ingress TRILL switch as described in Section 1.1/
>
> New:/ The requests to Pull Directory servers are typically derived from ARP
> [RFC826], ND [RFC4861], RARP [RFC903], or SEND [RFC3971] messages or data
> Layer 2 frames with unknown unicast destination MAC addresses intercepted by
> an ingress TRILL switch as described in Section 1.1/
>
> Reason: SEND mechanisms need to be clearly specified in the draft.  Suresh
> Krishnan mentioned this on the ARP optimization draft.

OK.

> #3 p. 19, section 3.2.1 paragraph 1, sentence 3
>
> Old: /The priority of the channel message is a mapping of the
>    priority of the frame being ingressed that caused the query with the
>    default mapping depending, per Data Label, on the strategy (see
>    Section 4) or a configured priority (DirGenQPriority, Section 3.9)
>    for generated queries./
>
> New:/ The priority of the channel message is a mapping of the
>    priority of the ingress frame which caused the query combined with the
>    default mapping per Data Label depending on the strategy for generated
>    queries (see Section 4) or a configured priority (DirGenQPriority,
> Section 3.9/.
>
> Reason: Clarify sentences.

I agree this could use clarification. How about:

   The priority of the channel message is a mapping
   of the priority of the ingressed frame that caused the query.
   The default mapping depends, per Data Label, on the strategy
   (see Section 4) or a configured priority (DirGenQPriority, Section
   3.9) for generated queries.

> #4, p. 33 section 3.5.1 paragraph 3
>
> Old:/ The Bridge shown might be a complex bridged LAN or might be absent
>    if, as shown for End Station 1, End Station 2 was dual ported with
>    point-to-point Ethernet links to RB1 and RB2./
>
> New:/The Bridge shown might be a complex bridged LAN, a LAN without a bridge
> (as shown in End station 1), or connected via point-to-point links (as shown in
> End Station 2’s which is connected through a bridge with point-to-point
> Ethernet links to
> RB1 and RB2./
>
> Reason: Clarify the sentences

OK.

> #5, p. 33 section 3.5.1 paragraph 4 sentence 1.
>
> Old:./
>    Because an indirect Pull Directory server discards information it has
>    cached from queries to an end station Pull Directory server if it
>    loses adjacency to that server (Section 3.7), if it knowns that such
>    information may be cached at RBridge clients and has no other source
>    for the information, it MUST send Update Messages to those clients
>    withdrawing the information/
>
> New: /Since an indirect Pull Directory server discards information it has
>      cached from queries to an end station Pull Directory server if it
>      loses adjacency to the server (Section 3.7), if it detects that
>      information may be cached at RBridge clients and has no other source
>      for the information, it MUST send Update Messages to those clients
>      withdrawing the information/
>
> Words changed – in bold
>
> Why: anthropomorphism – TRILL switches do not know.  TRILL switches detect
> based on logic.
>
> Why: Because/since – both indicate causes, but “since” seems to indicate an
> ordering that this paragraph suggests.

OK.

> #6: p. 43, 4th paragraph beginning with Although some …
>
> Current text:
>    /Although some of the ports sending TRILL ES-IS PDUs are on end
>    stations and thus not on routers (TRILL switches), they nevertheless
>    may make use of the Router Capability (#242) and MT-Capability (#222)
>    IS-IS TLVs to indicate capabilities as elsewhere specified./
>
> It would be good to indicate where these capabilities are specified.

OK, we can add a reference to RFC 7176

> #7 p. 44, section 6 – Security considerations
>
> After the SEC-DIR review comes in, consider if the end-system engage
> requires some extra text on privacy related to the end-systems.
>
> Since Donald and Radia are much better at all types of security, please
> consider this as a “please check”.   Kathleen and Stephen are focused on
> this work.

We could add something about edge RBridges being more aware of what IP
addresses are being used.

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