[trill] Spencer Dawkins' No Objection on draft-ietf-trill-pseudonode-nickname-06: (with COMMENT)

"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Tue, 15 September 2015 21:26 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 30A361B2A10; Tue, 15 Sep 2015 14:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id z4czP_GOaNGr; Tue, 15 Sep 2015 14:26:53 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 390D41B2A03; Tue, 15 Sep 2015 14:26:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Spencer Dawkins" <spencerdawkins.ietf@gmail.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150915212653.18348.80706.idtracker@ietfa.amsl.com>
Date: Tue, 15 Sep 2015 14:26:53 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/DoMBskYVejrRg-DuwgLt9tBz08g>
Cc: draft-ietf-trill-pseudonode-nickname.shepherd@ietf.org, trill-chairs@ietf.org, draft-ietf-trill-pseudonode-nickname@ietf.org, draft-ietf-trill-pseudonode-nickname.ad@ietf.org, trill@ietf.org, d3e3e3@gmail.com
Subject: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-pseudonode-nickname-06: (with COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
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, 15 Sep 2015 21:26:58 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-trill-pseudonode-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:


This was an easy document for me to read through (I have some exposure to
TRILL but am not skilled in the art). Thank you for that.

I did have some questions, but nothing at Discuss level. 

In this text:


   Other methods are possible; for example the
   specification in this document and the specification in [MultiAttach]
   could be simultaneously deployed for different AAE groups in the same
   campus. It is RECOMMENDED that only one method be adopted in a TRILL
   campus. For example, if the method is [MultiAttach] is used, TRILL
   switches need to support the capability indicated by the Capability
   Flags APPsub-TLV as specified in Section 4.2 of [MultiAttach]. If the
   method defined in this document is adopted, TRILL switches need to
   support the Affinity sub-TLV defined in [RFC7176] and [CMT]. For a
   TRILL campus that deploys both AAE methods, TRILL switches are
   required to support both methods.
I'm not thinking that RECOMMENDED is an RFC 2119 RECOMMENDED, but more
broadly, I THINK this paragraph is saying, "using multiple methods on a
TRILL campus will work, but if you use multiple methods, all of the TRILL
switches on the campus MUST support both methods". Did I get that right?

If so ... you might give some justification for adopting only one method
(my guesses were capital expense? operating expense? complexity in
troubleshooting?), and perhaps even some explanation why you might adopt
more than one method (I was guessing that you'd use more than one because
some of your equipment doesn't support the method you want to use, but if
TRILL switches have to support both methods, that isn't the reason, is

In this text:

3. Virtual RBridge and its Pseudo-nickname

   Since RBv is not a physical node and no TRILL frames are forwarded
   between its ports via an LAALP, pseudo-node LSP(s) MUST NOT be
   created for an RBv. RBv cannot act as a root when constructing
   distribution trees for multi-destination traffic and its pseudo-
   nickname is ignored when determining the distribution tree root for
   TRILL campus [CMT]. So the tree root priority of RBv's nickname MUST
   be set to 0, and this nickname SHOULD NOT be listed in the "s"
   nicknames (see Section 2.5 of [RFC6325]) by the RBridge holding the
   highest priority tree root nickname.
what happens if this SHOULD NOT is ignored? Do things still work?