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

[Donald Eastlake <[e-mail]>]

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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]


On Tue, Mar 13, 2018 at 11:50 AM, Donald Eastlake <[e-mail]> wrote:
> Hi Alvaro,
>
> On Tue, Mar 6, 2018 at 12:37 PM, Alvaro Retana <[e-mail]> 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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]