Hi Alvaro,

On Tue, Mar 6, 2018 at 12:37 PM, Alvaro Retana <aretana.i...@gmail.com> wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-multilevel-unique-nickname-06: No Objection
> ...
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> (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.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

trill mailing list

Reply via email to