[trill] Alvaro Retana's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)
Alvaro Retana <aretana.ietf@gmail.com> Tue, 06 March 2018 17:37 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1])
by ietfa.amsl.com (Postfix) with ESMTP id 8964A120725;
Tue, 6 Mar 2018 09:37:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alvaro Retana <aretana.ietf@gmail.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-trill-multilevel-unique-nickname@ietf.org,
Susan Hares <shares@ndzh.com>, trill-chairs@ietf.org, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.74.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152035784351.28389.5797511383094691398.idtracker@ietfa.amsl.com>
Date: Tue, 06 Mar 2018 09:37:23 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/X4x-qyIn6qENbEp-tk1HBN1iw5s>
Subject: [trill] Alvaro Retana's No Objection on
draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>,
<mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>,
<mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2018 17:37:24 -0000
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.
- [trill] Alvaro Retana's No Objection on draft-iet… Alvaro Retana
- Re: [trill] Alvaro Retana's No Objection on draft… Donald Eastlake
- Re: [trill] Alvaro Retana's No Objection on draft… Donald Eastlake
- Re: [trill] Alvaro Retana's No Objection on draft… Alvaro Retana