Re: [trill] Alissa Cooper's Discuss on draft-ietf-trill-smart-endnodes-10: (withDISCUSS and COMMENT)

[hu.fangwei]

Hi，Alissa Cooper


Thanks for your review and comments. 


The new version(version 10)  has updated to fix your comments.


The format of Smart-MAC APP sub-TLV and the text  has been changed to the 
following:



The length of F,M,RSV,VLAN/FGL data Label is 4 bytes. and the length of 
VLAN/FGL Data Label field is 24 bits.





 +-+-+-+-+-+-+-+-+
 |Type=Smart-MAC | (1 byte)
 +-+-+-+-+-+-+-+-+
 | Length | (1 byte)
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|M|RSV| VLAN/FGL Data Label | (4 bytes)
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | MAC (1) (6 bytes) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | . |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | MAC (N) (6 bytes) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 
Smart-MAC APPsub-TLV


 o VLAN/FGL Data Label: 24bits. If F is 1, this field is a 24-bit
 FGL Data Label for all subsequent MAC addresses in this APPsub-
 TLV. Otherwise, if F is 0, the lower 12 bits is the VLAN of all
 subsequent MAC addresses in this APPsub-TLV, and the upper 12 bits
 is not used(sent as zero and ignored on receipt). If there is no
 VLAN/FGL data label specified, the VLAN/FGL Data Label is zero.








Regards.


Fangwei.



原始邮件



发件人：AlissaCooper 
收件人：The IESG 
抄送人：draft-ietf-trill-smart-endno...@ietf.org 
trill-cha...@ietf.org 
sha...@ndzh.com trill@ietf.org 

日 期 ：2018年03月07日 04:45
主 题 ：Alissa Cooper's Discuss on draft-ietf-trill-smart-endnodes-10: 
(withDISCUSS and COMMENT)


Alissa Cooper has entered the following ballot position for
draft-ietf-trill-smart-endnodes-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/



--
DISCUSS:
--

This should hopefully be easy to fix and was pointed out by the Gen-ART
reviewer:

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.

Please make it clear both in the diagram and in the text what the expected
lengths of the fields are -- I find it particularly confusing that the number
of bits pictured doesn't align with the number of bits specified in the text
per field.


--
COMMENT:
--

Please also look at the Gen-ART reviewer's other comments.___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alissa Cooper's Discuss on draft-ietf-trill-vendor-channel-00: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi Alissa,

On Tue, Mar 6, 2018 at 3:28 PM, Alissa Cooper  wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-trill-vendor-channel-00: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> I'm having trouble understanding what function this specification serves given
> that the RBridge Channel Protocol registry has a range reserved already for
> private use and that the document doesn't specify any requirements around
> vendor-specific protocol semantics. So any implementation of this that needs 
> to
> interoperate with another implementation will need to do so according to some
> specification generated by the vendor, and that specification can select a 
> code
> point from the private use range. What does allocating a single code point for
> all such vendor-specific protocols achieve, aside from specifying a structured
> way of conveying the OUI/CID (which seems superfluous anyway for multiple
> implementations from a single vendor interoperating with each other)?

What if two TRILL campuses using the same private code point for
incompatible purposes are accidentally interconnected?

What if someone wants to use TRILL switches from two different vendors
each of which uses the same private code point for incompatible
purposes? Say one vendor makes highly flexible/desirable edge TRILL
switches while the other make particularly cost effective core TRILL
switches or particularly nifty Level 1 / Level 2 border TRILL
switches, or whatever.

"private" code points seem pretty flakey compared with the more robust
mechanism in this draft.

Maybe this document should also depredate the use of private code points.

> --
> COMMENT:
> --
>
> I agree with the Gen-ART reviewer that the text in the Acknowledgements 
> section
> is not appropriate. See RFC 7322.

OK.

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

[trill] Opsdir telechat review of draft-ietf-trill-multi-topology-05

[Tim Chown]

Reviewer: Tim Chown
Review result: Ready

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document specifies extensions to the TRILL protocol to support
multi-topology routing of unicast and multi-destination traffic based on IS-IS
multi-topology as specified in RFC 5120.

The document is well-structured and written, and Ready for publication.


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Deborah Brungard's No Objection on draft-ietf-trill-transport-over-mpls-07: (with COMMENT)

[Deborah Brungard]

Deborah Brungard has entered the following ballot position for
draft-ietf-trill-transport-over-mpls-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-transport-over-mpls/



--
COMMENT:
--

Agree with Gen-ART reviewer, section 6 needs to be clarified
with respect to PW header and MPLS header processing.


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Kathleen Moriarty's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

[Kathleen Moriarty]

Kathleen Moriarty has entered the following ballot position for
draft-ietf-trill-multilevel-unique-nickname-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-unique-nickname/



--
COMMENT:
--

Thank you for responding to the SecDir review.  I also agree with Roman's
questions on normative language and would like to see a response to his
suggestions. https://www.ietf.org/mail-archive/web/secdir/current/msg07947.html


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

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

[Alissa Cooper]

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, hu.fang...@zte.com.cn 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 
> 
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/ 
> 
> Htmlized:   
> https://tools.ietf.org/html/draft-ietf-trill-smart-endnodes-10 
> 
> Htmlized:   
> 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 
> 
> 
> 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 mailto:rjspa...@nostrum.com>>
> 收件人：gen-...@ietf.org   >
> 抄送人：i...@ietf.org   >draft-ietf-trill-smart-endnodes@ietf.org 
>  
>  >trill@ietf.org 
>  mailto:trill@ietf.org>>
> 日 期 ：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
> 
> .
> 
> 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
> trill@ietf.org 
> https://www.ietf.org/mailman/listinfo/trill 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org 
> https://www.

[trill] Alissa Cooper's Discuss on draft-ietf-trill-smart-endnodes-10: (with DISCUSS and COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-trill-smart-endnodes-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/



--
DISCUSS:
--

This should hopefully be easy to fix and was pointed out by the Gen-ART
reviewer:

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.

Please make it clear both in the diagram and in the text what the expected
lengths of the fields are -- I find it particularly confusing that the number
of bits pictured doesn't align with the number of bits specified in the text
per field.


--
COMMENT:
--

Please also look at the Gen-ART reviewer's other comments.


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] [Gen-art] Genart telechat review of draft-ietf-trill-vendor-channel-00

[Alissa Cooper]

Joel, thanks for your review. I agree with your comment. I entered a DISCUSS 
ballot as I’m a bit unclear what this spec is achieving. 

Alissa

> On Feb 26, 2018, at 6:01 PM, Donald Eastlake  wrote:
> 
> Hi Joel,
> 
> On Mon, Feb 26, 2018 at 1:24 PM, Joel Halpern  > wrote:
> Reviewer: Joel Halpern
> Review result: Ready
> 
> 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
> 
>  >.
> 
> Document: draft-ietf-trill-vendor-channel-00
> Reviewer: Joel Halpern
> Review Date: 2018-02-26
> IETF LC End Date: 2018-03-06
> IESG Telechat date: 2018-03-08
> 
> Summary: This document is ready for publication as a Proposed Standard
> 
> Major issues: N/A
> 
> Minor issues: N/A
> 
> Nits/editorial comments:
> Why does the acknowledgements say:
> "The document was prepared in raw nroff. All macros used were defined
> within the source file."
> ?
> 
> Why not? It's true. I've seen a number of draft with credit in them for MS 
> Word templates and the like. Shouldn't people know their are still drafts 
> being prepared with nroff?

> 
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com  
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org 
> https://www.ietf.org/mailman/listinfo/gen-art 
> 
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alissa Cooper's Discuss on draft-ietf-trill-vendor-channel-00: (with DISCUSS and COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-trill-vendor-channel-00: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-vendor-channel/



--
DISCUSS:
--

I'm having trouble understanding what function this specification serves given
that the RBridge Channel Protocol registry has a range reserved already for
private use and that the document doesn't specify any requirements around
vendor-specific protocol semantics. So any implementation of this that needs to
interoperate with another implementation will need to do so according to some
specification generated by the vendor, and that specification can select a code
point from the private use range. What does allocating a single code point for
all such vendor-specific protocols achieve, aside from specifying a structured
way of conveying the OUI/CID (which seems superfluous anyway for multiple
implementations from a single vendor interoperating with each other)?


--
COMMENT:
--

I agree with the Gen-ART reviewer that the text in the Acknowledgements section
is not appropriate. See RFC 7322.


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alissa Cooper's Discuss on draft-ietf-trill-vendor-channel-00: (with DISCUSS)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-trill-vendor-channel-00: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-vendor-channel/



--
DISCUSS:
--

I'm having trouble understanding what function this specification serves given
that the RBridge Channel Protocol registry has a range reserved already for
private use and that the document doesn't specify any requirements around
vendor-specific protocol semantics. So any implementation of this that needs to
interoperate with another implementation will need to do so according to some
specification generated by the vendor, and that specification can select a code
point from the private use range. What does allocating a single code point for
all such vendor-specific protocols achieve, aside from specifying a structured
way of conveying the OUI/CID (which seems superfluous anyway for multiple
implementations from a single vendor interoperating with each other)?




___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] [Gen-art] Genart telechat review of draft-ietf-trill-multi-topology-05

[Alissa Cooper]

Brian, thanks for your review. I have entered a No Objection ballot.

Alissa

> On Mar 2, 2018, at 5:08 PM, Brian Carpenter  
> wrote:
> 
> Reviewer: Brian Carpenter
> Review result: Ready
> 
> Gen-ART Last Call + Telechat review of draft-ietf-trill-multi-topology-05
> 
> 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-trill-multi-topology-05.txt
> Reviewer: Brian Carpenter
> Review Date: 2018-03-02
> IETF LC End Date: 2018-03-06
> IESG Telechat date: 2018-03-08
> 
> Summary: Ready
> 
> 
> Comment:
> 
> 
> This is a rushed review for reasons outside my control. Also, only
> a TRILL expert could review it effectively. As far as I can tell,
> it's a well written document.
> 
> This is a case where I wish RFC1264 still applied. I'm disappointed
> not to see an RFC 7942 Implementation Status section.
> 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alvaro Retana's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

[Alvaro Retana]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-multilevel-unique-nickname-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-unique-nickname/



--
COMMENT:
--

(1) The nickname selection process for multilevel is not backwards compatible
because of the use of the NickBlockFlags APPsub-TLV.  That is ok since the
border RBridges can recognize "old" Rbridges (ones that don't support this
specification) in an area. A couple of related comments:

(1.1) Section 4.4. (Capability Indication) says that "Non border RBridges in an
area SHOULD understand the NickBlockFlags APPsub-TLV."  That statement is
somewhat contradictory (maybe that's not the right word, but the only one that
comes to mind):

- On one hand, non border RBridges could be just be "old" (ones that don't
support this specification).  We can't normatively specify something that by
definition nodes that don't support this specification won't know about.

- On the other hand, if the non border Rbridge does support this specficiation,
then why wouldn't it understand the NickBlockFlags APPsub-TLV?  IOW, why isn't
the "SHOULD" a "MUST" instead?  When is it ok to not do it?

All this is to say that I think that "SHOULD" should not be used normatively. 
s/SHOULD/should

(1.2) Given that rfc6325 specifies a single Level 1 network, it is reasonable
to expect that networks implementing these multilevel extensions will grow from
a single area to multiple.  It would be ideal to include Deployment
Considerations to discuss what a Migration Path would look like.

(2) Maybe I missed it somewhere...  The Security Considerations section says
that "border RBridges need to fabricate the nickname announcements...Malicious
devices may also fake the NickBlockFlags APPsub-TLV to announce a range of
nicknames."  I'm sure that malicious devices don't only include ones that are
unauthenticated, but may include over or under claiming by existing border
RBridges or even non border RBridges originating the NickBlockFlags APPsub-TLV.

(2.1) Is the origination of the NickBlockFlags APPsub-TLV restricted to border
RBridges?  If so, why isn't there a check to make sure that the NickBlockFlags
APPsub-TLV came from a border RBridge?

(2.2) rfc8243 talks about the (potential) ability of border RBridges to
"discover each other...by using the IS-IS "attached bit" [IS-IS] or by
explicitly advertising in their LSP "I am a border RBridge".  But I didn't see
these options/mechanisms mentioned in this document.


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill