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

Donald Eastlake <d3e3e3@gmail.com> Fri, 21 July 2017 09:07 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CDDFD129A96 for <trill@ietfa.amsl.com>; Fri, 21 Jul 2017 02:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BJY348WNxonW for <trill@ietfa.amsl.com>; Fri, 21 Jul 2017 02:07:31 -0700 (PDT)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 F13E912EB2B for <trill@ietf.org>; Fri, 21 Jul 2017 02:07:30 -0700 (PDT)
Received: by mail-io0-x236.google.com with SMTP id m88so11780326iod.2 for <trill@ietf.org>; Fri, 21 Jul 2017 02:07:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lzNRIMBnvshIniWqXUqe2pWmFInEjNBKC7XC63QwZxM=; b=IUQvP+PTTT9MJQ3aNBOnwv5XyEO4b5jwJ+YhNnxWYKYuay49/I6SofME+MC6Rpb9mz or6LsAZ8qkUL+ZlONkw0ogv6ZRCuAYQtjuEtmEjdY5whY83pATqCUpljkSOmisCWcYso LjdUqJgrEM+/61dT5PfQ2VqGPrT9zuoUoLzqQWtafpdu7moC+Dw2kCBZe/hK1nKO/bsa xXfCLoGqdOm3ovzL3KFyaK5+2TpXhow0U4S8KjJGBpWkQ9oFFOQRTBdvCzY+H09aXmDw e65SyBAjbaMgF1lywbKffKx+jS9nRkEXOuJVd+ZRLG96VyN7ArejL0Rj2bd5d0WyL0gu /jNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lzNRIMBnvshIniWqXUqe2pWmFInEjNBKC7XC63QwZxM=; b=DLxv2Jw4LgbUJeR6WHOJ2wCkrTQu1j52xDvvxMNQwE3gSNtt8LPfirKIyADC7LDb3C +Hww+tIPAOaznR7lavNxCNUbavNxXOZWMWk0HPNAST6COL87MM6XamWOiqgFP/kDfQZ/ JC4AxO79fbIOqy1saKyTi9bjTGODrVjbux5FiSrSnu+AWQQ6SXdFQ3cJ9laAAzV2+jVL eg3HGoPuPK5sAVYpLQcw8X40JVVZDeWG1FGqUdyKUOJ4cbijCuyiezqkV4IPxhD4vKOD DrWckoMG/FkbFA5ZglsKpSFByceegMxHwFiWrB6w0bLXzYm32QPbayzdq/F44INunliz Jqdg==
X-Gm-Message-State: AIVw113qCLOM/WAjCQ/M4IkbcQH/ywd8a2+2X7PoMdAjSx7u7YpRNX/h S+RbmAQtHR5w6LxGCGbLF1IQnlsfDFNaIXI=
X-Received: by with SMTP id q140mr6326782iod.77.1500628050236; Fri, 21 Jul 2017 02:07:30 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Jul 2017 02:07:14 -0700 (PDT)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 21 Jul 2017 05:07:14 -0400
Message-ID: <CAF4+nEGK6HTi2jRQkD8pvN4k29b71G5mopg8JuxtkaBy+o1nfg@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/PX-oOfyyksgc4yPSYnAhQrrJtjc>
Subject: [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:07:33 -0000

I support this draft and have the following comments:


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

"The mechanism for querying a directory is out of scope for this
document." -> "The mechanism for querying a directory is given in


Change ".While when" to ". When"

"nicknamae" -> "nickname"

There are also some other more minor editorial things I can
communicate directly to the principal author.

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