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

From: Alvaro Retana <[email-masked]>
Date: Tue, 06 Mar 2018 09:37:23 -0800

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.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 13 Mar 2018 11:50:53 -0400

Hi Alvaro,

On Tue, Mar 6, 2018 at 12:37 PM, Alvaro Retana <[email-masked]> wrote:
> ...

Sounds reasonable to me.

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

> 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-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 14 Mar 2018 21:24:51 -0400

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

---

From: Alvaro Retana <[email-masked]>
Date: Sun, 18 Mar 2018 10:03:08 -0400

Thanks Donald!

On March 15, 2018 at 1:25:07 AM, Donald Eastlake ([email-masked]) wrote: