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

Donald Eastlake <> Tue, 13 March 2018 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5481A1205F0; Tue, 13 Mar 2018 08:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hg3P5gCFGRrT; Tue, 13 Mar 2018 08:51:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A14A12E054; Tue, 13 Mar 2018 08:51:10 -0700 (PDT)
Received: by with SMTP id k21so672809ioc.2; Tue, 13 Mar 2018 08:51:10 -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=rll8QwxgA5Wam8ek9DpAP/LEXCfTdgOpRpkf7RtY28s=; b=FuNkUsmhxDV+2kjtvr15coAs/ygXvcCIswi5XKA1wVKROAt8GI2kQ8SlQ4A5XOzYtU nt2sAV0fPt3w7OpzPRX3pshXU20usUJV4MflMyOrVwilqAZQht+Umer69SPwqyyfg9L1 BZ5ZJpsWORcFNIYqdDSdkF566BW02KD9xzCBftoepUkQ0UC2Fy0IWInfTaO3g2w0z98z JKU/lu6GnJAIRz50MtKNMrSrqDUc+Nd+pIkeLremGFYpqdN2iWaCyJoEWkUEISa5/EkC K6R2iRYkShiHfSobPmc1uxMaF0kBr+iixnFbmzA09kviGT9BCAE1fBJCMnuTkeePNagF gzfg==
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=rll8QwxgA5Wam8ek9DpAP/LEXCfTdgOpRpkf7RtY28s=; b=cu2RaFcakvmiDmSdct7exKH+jcedG0ro1XZ/gpwxc+fXRV/0arnKg39JIa0XtMpYKD qnuOaPTP1U2GGGf3MO63eBmYBbQ1yOXU+5tVs4my2lJQvpMY+VT3lqGVOSZ5GH1+hvxs nqGRHTb0+85gilbLqsV5zfa8z/0MbpXqB1buScgg80OCqactjxh5rTrHFqRWUUZH8eJw u6W1YHrlTlNSani0n4HEptchpaw4T+FznKsKxeMsC9lrnhvAedwyp/AygSAL0ErZuZLg JOS5WSUxlGzFRKZcmPHMbVPLFqcE4o6M1dwP1eKamQkgdC9ID2+5ki5j+Fj5ZCN8H3wJ EDlg==
X-Gm-Message-State: AElRT7Ga5rgY8z5HccoIRK0yWdpZ4Chp+9uTlN69s7qpOd56Pi+A/rl9 OTJacMrqZM470jfem2xHpLRZamzZE6nt1U3MYTc2Hw==
X-Google-Smtp-Source: AG47ELud75l/S5/6EE5ZqGaj4ojbW7iZ5Ut9DEFWBH+4obApjXfMm2cz4BNQwfTTSAblCyrMJTmIvhrB39c6Znv+79U=
X-Received: by with SMTP id f25mr1313175iob.14.1520956269740; Tue, 13 Mar 2018 08:51:09 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 13 Mar 2018 08:50:53 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Tue, 13 Mar 2018 11:50:53 -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: Tue, 13 Mar 2018 15:51:17 -0000

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.

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