Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames
draft-ietf-trill-multilevel-unique-nickname-07

Balloting NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem." sense.

(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.

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?

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