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 d3e...@gmail.com On Fri, Jul 21, 2017 at 5:07 AM, Donald Eastlake <d3e...@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 > d3e...@gmail.com _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
