Re: [trill] Comments on draft-ietf-trill-smart-endnodes

Donald Eastlake <d3e3e3@gmail.com> Fri, 21 July 2017 09: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 51B3B12EB2B for <trill@ietfa.amsl.com>; Fri, 21 Jul 2017 02:26:10 -0700 (PDT)
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 8lA54OOzerkU for <trill@ietfa.amsl.com>; Fri, 21 Jul 2017 02:26:09 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 341CF131B5F for <trill@ietf.org>; Fri, 21 Jul 2017 02:26:02 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id h199so4863154ith.0 for <trill@ietf.org>; Fri, 21 Jul 2017 02:26:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qZFbNv7dMPTh7JzSh+0nklp/QRfTWYLZ+k6OCUZLafU=; b=sO3MVzZrCqryjxhRJN6utmsd5T5nJFNShDI8Z0hk5L2qasgPqjXZfCCQ2qxQfZO8h7 qnJYkK+ywgqiHbCc9B0igs4Yk+apddQTcIcE0pY6EprriZKxcZaGH7ZXmOa3j7zgwnlx MwHnCqHcPcLcBB5ekMTmMvYq1G68VbbnZhVY44OJ0X9Av++MShVCEmXJmjDEI2qeOSad pd/+2SusS7V3l9+RS/j2ydoXtL18S7f/Jm/w/YJmzETqoB78WXUNOaUNP5hpy1j1pbtl cPhrg6wvECgWdrx74YXJvobSNi6MzCxtnHoWx/SNYdZiVXK6hEUGKzXvTvGnNMdBfKLq byBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qZFbNv7dMPTh7JzSh+0nklp/QRfTWYLZ+k6OCUZLafU=; b=XmB6PSWa/010snCMQuUeKn9wcm29uqo3kLVUZ+zzsGAAp5Nz6KEY7E5+tKyuK1R5pr Ft+Nd0c59B9FTYSwCk/5lwToXNiubkszkqc78nK6kf8Gnw4JXvoEosBRJ5vnCcHEHjaR kFT2pFR+zneePeDixA5SmW7TT2CycSkJ7bfiZAKXRaeJPaBD4+J6QwJ8nAlwaiuM2Btu E24R1K8kenwIubkog3CUcJQumTQteTzRAsJaYDa1xxw5rUGn4xsECXLrNDLgyfCdWpvA wFZkk6vYE7TTmBywEJIiwSpEhSaN0qW6pvq2N9wvQ7lcGpB8a6ZqRUTYaQEMNgyL8sDJ CraQ==
X-Gm-Message-State: AIVw112rMyVDfCCNsD44okOYc/ZW5x6XeiokNXofJrCPUZNo88SWF01B qTn+eH2i2W0jEuDAAjK76iDECEVXnnpJ
X-Received: by 10.36.123.83 with SMTP id q80mr76415itc.1.1500629161105; Fri, 21 Jul 2017 02:26:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.221 with HTTP; Fri, 21 Jul 2017 02:25:45 -0700 (PDT)
In-Reply-To: <CAF4+nEGK6HTi2jRQkD8pvN4k29b71G5mopg8JuxtkaBy+o1nfg@mail.gmail.com>
References: <CAF4+nEGK6HTi2jRQkD8pvN4k29b71G5mopg8JuxtkaBy+o1nfg@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 21 Jul 2017 05:25:45 -0400
Message-ID: <CAF4+nEE1xtG30nmd3FhXtBPiLjryz9D1PVX-k_btAU8gv_YC1w@mail.gmail.com>
To: "trill@ietf.org" <trill@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/Boyxm3Wv9RiNXqgNshe7ks2c62I>
Subject: Re: [trill] Comments on draft-ietf-trill-smart-endnodes
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: Fri, 21 Jul 2017 09:26:10 -0000

Hi,

Having just refreshed myself on both the smart-endnode and directory
assisted encap drafts, I think the smart-endnode draft should be
changed from using native RBridge Channel messages to using the TRILL
ES-IS specified in RFC 8171. ES-IS would allow a much larger amount of
data to be synchronized between edge-RBridges and smart endnodes, for
example if a smart endnode were actually some sort of gateway and was
handling a very large number of MAC addresses. Just how to use a
native RBridge Channel message, as is currently specified in this
draft, seems underspecified and would probably need a state diagram,
etc., to be complete.

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


On Fri, Jul 21, 2017 at 5:07 AM, Donald Eastlake <d3e3e3@gmail.com>; wrote:
> I support this draft and have the following comments:
>
> Technical
> -------------
>
> It is not made clear how Smart End Nodes learn the Designated VLAN of
> the link they are on or, considering the paragraph just before the
> Section 5.2 header, the Appointed Forwarder for a VLAN or the DRB. It
> seems to me the draft needs to say explicitly that the smart end node
> snoops on TRILL IS-IS Hellos. Also, it needs to say that a smart end
> node, when encapsulating traffic in VLAN X, needs to use the nickname
> of the appointed forwarder for VLAN X, regardless of which edge
> RBridge it sends the encapsulated frame to, to avoid MAC flip-flop at
> the egress RBridge.
>
> The point paragraph just before the Section 6 header provides two
> approaches to handling a hybrid local link (a hybrid link is one with
> both smart and non-smart end nodes on it). As a Proposed Standard and
> in accordance with TRILL's general design approach, the document needs
> to select one and make it be the default.
>
> Section 6 also has two alternatives and does not seem clear.
> Presumably there isn't a single link with SE1, RB1, and RB2 on it
> since that case is well handled by the smart end node using the
> appointed forwarder nickname regardless of which edge RBridge it sends
> the encapsulated user data to. So it must be that SE1 is dual ported.
> If so, probably these ports have different MAC addresses and I'm not
> sure what the problem is....
>
> I think it is inconsistent that IANA Considerations says "Smart-Hello"
> while near the start of the draft, the TLV is called
> "Smart-Parameters".
>
> "The mechanism for querying a directory is out of scope for this
> document." -> "The mechanism for querying a directory is given in
> [RFC8171]."
>
> Editorial
> -----------
>
> Change ".While when" to ". When"
>
> "nicknamae" -> "nickname"
>
> There are also some other more minor editorial things I can
> communicate directly to the principal author.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com