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

[Donald Eastlake <[e-mail]>]

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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]


On Fri, Jul 21, 2017 at 5:07 AM, Donald Eastlake <[e-mail]> 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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]