Robert, thanks for your review. I managed to ballot before reading the rest of this thread (sorry!), but I still think the diagram in 4.3 is confusing and not consistent with the text. To my eye row 3 shows two bytes’ worth of fields but the label says “4 bytes.” RSV is depicted as 2 bits but the text says it is 6 bits. The combination of these two inconsistencies makes it hard to know what the actual lengths are supposed to be.
Thanks, Alissa > On Mar 1, 2018, at 10:46 PM, [email protected] wrote: > > Hi, Sparks > > Thanks for your review and comments. > > A new version(version 10) draft is submitted to fix the issues. > > Regards > > Fangwei. > > > > > > A new version of I-D, draft-ietf-trill-smart-endnodes-10.txt > has been successfully submitted by Fangwei Hu and posted to the > IETF repository. > > Name: draft-ietf-trill-smart-endnodes > Revision: 10 > Title: TRILL Smart Endnodes > Document date: 2018-03-01 > Group: trill > Pages: 15 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-trill-smart-endnodes-10.txt > <https://www.ietf.org/internet-drafts/draft-ietf-trill-smart-endnodes-10.txt> > Status: > https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/ > <https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/> > Htmlized: > https://tools.ietf.org/html/draft-ietf-trill-smart-endnodes-10 > <https://tools.ietf.org/html/draft-ietf-trill-smart-endnodes-10> > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-trill-smart-endnodes-10 > <https://datatracker.ietf.org/doc/html/draft-ietf-trill-smart-endnodes-10> > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-smart-endnodes-10 > <https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-smart-endnodes-10> > > Abstract: > This draft addresses the problem of the size and freshness of the > endnode learning table in edge RBridges, by allowing endnodes to > volunteer for endnode learning and encapsulation/decapsulation. Such > an endnode is known as a "Smart Endnode". Only the attached edge > RBridge can distinguish a "Smart Endnode" from a "normal endnode". > The smart endnode uses the nickname of the attached edge RBridge, so > this solution does not consume extra nicknames. The solution also > enables Fine Grained Label aware endnodes. > > > > > 原始邮件 > 发件人：RobertSparks <[email protected] <mailto:[email protected]>> > 收件人：[email protected] <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> > 抄送人：[email protected] <mailto:[email protected]> <[email protected] > <mailto:[email protected]>>[email protected] > <mailto:[email protected]> > <[email protected] > <mailto:[email protected]>>[email protected] > <mailto:[email protected]> <[email protected] <mailto:[email protected]>> > 日 期 ：2018年02月28日 04:24 > 主 题 ：[trill] Genart telechat review of draft-ietf-trill-smart-endnodes-08 > Reviewer: Robert Sparks > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-trill-smart-endnodes-08 > Reviewer: Robert Sparks > Review Date: 2018-02-27 > IETF LC End Date: 2018-03-06 > IESG Telechat date: 2018-03-08 > > Summary: Ready with issues > > Major issues > > 1) In section 4.3 the bullet describing the F bit does not parse. There are > two > instances of "Otherwise" that do not work together. > > 2) All of section 4.3 is confusing as to what the length of the TLV really is. > Row 3 in the diagram says 2 bytes or 4 bytes, but the number of bits called > out > in bullets 4 and 5 below it don't seem to add up to those things. Maybe it > would > be better to draw a diagram with F=0 and a separate diagram with F=1 > > 3) I think the security considerations section should call out again what an > RB > should do if it gets message that looks like it's from a SE, containing the > right nickname, but the RB hasn't done the right Smart-Hello handshaking with > that SE already. What would keep a lazy implementation (or one driven by > product managers picking and choosing features) from just forwarding a message > from a malicious element that just happened to know the RB's nickname? > > Nits > > Terminology: The definition of Transit RBridge says it's also named as a > Transit Rbridge? > > > _______________________________________________ > trill mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/trill > <https://www.ietf.org/mailman/listinfo/trill> > > _______________________________________________ > Gen-art mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
