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

Donald Eastlake <> Fri, 21 July 2017 09:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51B3B12EB2B for <>; Fri, 21 Jul 2017 02:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8lA54OOzerkU for <>; Fri, 21 Jul 2017 02:26:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 341CF131B5F for <>; Fri, 21 Jul 2017 02:26:02 -0700 (PDT)
Received: by with SMTP id h199so4863154ith.0 for <>; Fri, 21 Jul 2017 02:26:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id q80mr76415itc.1.1500629161105; Fri, 21 Jul 2017 02:26:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Jul 2017 02:25:45 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Fri, 21 Jul 2017 05:25:45 -0400
Message-ID: <>
To: "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [trill] Comments on draft-ietf-trill-smart-endnodes
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Jul 2017 09:26:10 -0000


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.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

On Fri, Jul 21, 2017 at 5:07 AM, Donald Eastlake <> 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