Re: [trill] [Gen-art] Genart telechat review of draft-ietf-trill-smart-endnodes-08

[Alissa Cooper <[e-mail]>]

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, [e-mail] 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 <[e-mail] <mailto:[e-mail]>>
> 收件人：[e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> 抄送人：[e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>[e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>[e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> 日 期 ：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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/trill <https://www.ietf.org/mailman/listinfo/trill>
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>