Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames
RFC 8397

Note: This ballot was opened for revision 05 and is now closed.

Alvaro Retana No Objection

Comment (2018-03-06 for -06)
No email
send info
(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.

Warren Kumari No Objection

Comment (2018-03-07 for -06)
No email
send info
Balloting NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem." sense.

(Alia Atlas; former steering group member) Yes

Yes ( for -05)
No email
send info

(Adam Roach; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Eric Rescorla; former steering group member) No Objection

No Objection (2018-03-08 for -06)
No email
send info
In the security considerations,  isn't the requirement not that you configure IS-IS authentication but that you actually have to require it on receipt? Or are these the same things.

Even with ordinary trill, can't you just spoof a lot of announcements with other people's nicknames? Why is this different?

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2018-03-06 for -06)
No email
send info
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

(Mirja K├╝hlewind; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Ben Campbell; former steering group member) No Record

No Record (2018-03-07 for -06)
No email
send info
Apologies, I ran out of time for this one.