Hi Alvaro, A -07 version of draft-ietf-trill-multilevel-unique-nickname has been posted with the intent of resolving your comment as per my response below.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] On Tue, Mar 13, 2018 at 11:50 AM, Donald Eastlake <[email protected]> wrote: > Hi Alvaro, > > On Tue, Mar 6, 2018 at 12:37 PM, Alvaro Retana <[email protected]> wrote: >> Alvaro Retana has entered the following ballot position for >> draft-ietf-trill-multilevel-unique-nickname-06: No Objection >> >> ... >> >> ---------------------------------------------------------------------- >> 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 > > Sounds reasonable to me. > >> (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? > > Such a check would add some complexity and it is not clear there would > be much gain as an RBridge that is forging NickBlockFlags APPsub-TLVs > would presumably just falsely claim it is a border RBridge by claiming > ownership of at least one Level 2 nickname. > >> (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. > > Border RBridges know they are border RBridges because, by > configuration, they are talking to both Level 1 and 2. They act > specially but it is not clear what good looking at the attached bit or > border RBridges advertising that explicitly in the LSP would do. If > you are in Level 2 and see some Level 2 RBridge advertising that it > owns Level 1 nicknames, you know it is a border RBridge and likewise, > if you are in Level 1 and see some Level 1 RBridge advetising that it > owns Level 2 nicknames, you know it is a border RBridge. And the > nicknames are distinguished by being taken from mutually exclusive > ranges of nicknames. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
