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

Donald Eastlake <> Thu, 15 March 2018 01:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8A1112D7F5; Wed, 14 Mar 2018 18:25:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W0BJ8z1sN-Vw; Wed, 14 Mar 2018 18:25:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E52F126DFB; Wed, 14 Mar 2018 18:25:07 -0700 (PDT)
Received: by with SMTP id j7-v6so7084312ita.3; Wed, 14 Mar 2018 18:25:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cUFXsBQw++7ilwECD/I32pd1UszVIJ7U8M4yJpd7yzQ=; b=BIAlOmPSW6BMwHyvjXKGdaSvnI/e0Kob7J45Ge6KU67nEHZFMNmtxNW/SsLEzo5L98 vKJ4j703RL9AhxVHlUpiC/yvdE2drm9zUOOrpJ/1Xt9MqCQcEfiPYLeQ1SaSRBzcAMgj X7LH00KMRi+pdxeetz9kl6tJ4IqLxPJtVgbQDt3B4JBcD0YoN+wZpZN9vFiudpnW1Tn9 M1C2PPS/fbursONNdikbuiBr3c2Gw8r0uyzlXAWRA2FQBbS78h76dDDjkxNjqN7AzAOm ca7RJh3q7U3cqMsQLsHFkkuFLjfb3tuyneOW4gcr4dwn5vvk614S+9dgYUurWLjncZh2 7axw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cUFXsBQw++7ilwECD/I32pd1UszVIJ7U8M4yJpd7yzQ=; b=lIWbMUNETCL9xGw0Tx7g+NyFSOaG2Qzb2PprxoSBwkRolOI7d94GCBWK8qIuD1lYJc l53kQomjvxf0bCEwrS+AdU7ybS1F1Qfc/5K7Ogs4XBIuoxWdYX0WJzOzPJQ6FnBPZ+do CL05OQGisL5f1n/8mQlnuAhOVKG4TjPXveULz3T9L5fnWs8XzDQdzoOSSVvNu3JCqlyP v47DtpGpPhTzGN+wyFx5UOjnr7JgmSSH85lQ6cFvqIi1/bivvUQm+Mt9pbP+vbfZ7AN/ 4c/g9nvdc2GN4bdL5KLbYeix8J6p3cc+TsANWvFXOPURn4RDsr9bdnHvrMAkVLS99JqQ GlQQ==
X-Gm-Message-State: AElRT7GSqdrphcEGOKZOcoxKMFfoYBItk4nbzh6JYmEfCcFizzX2xUFM rx14FsQWowvW60Qv4kelT3ucEY48MeTBfhODz3E=
X-Google-Smtp-Source: AG47ELuEzeqgZzvajn38eANNpOe4Kqav/Mk2ui9WbYbC3uEBE6w+gDC6vuQvq0hLq0cdHaDSPckN5yL/+JNVuErLjC4=
X-Received: by with SMTP id b193mr4303416itb.105.1521077106934; Wed, 14 Mar 2018 18:25:06 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 14 Mar 2018 18:24:51 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Donald Eastlake <>
Date: Wed, 14 Mar 2018 21:24:51 -0400
Message-ID: <>
To: Alvaro Retana <>
Cc: The IESG <>,, Susan Hares <>,, trill IETF mailing list <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Mar 2018 01:25:09 -0000

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

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

On Tue, Mar 13, 2018 at 11:50 AM, Donald Eastlake <> wrote:
> Hi Alvaro,
> On Tue, Mar 6, 2018 at 12:37 PM, Alvaro Retana <> 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 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