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

[Alvaro Retana <[e-mail]>]

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.