[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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: https://datatracker.ietf.org/doc/draft-ietf-trill-pseudonode-nickname/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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: Introduction 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 it?) 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?
- [trill] Spencer Dawkins' No Objection on draft-ie… Spencer Dawkins
- Re: [trill] Spencer Dawkins' No Objection on draf… Mingui Zhang
- Re: [trill] Spencer Dawkins' No Objection on draf… Spencer Dawkins at IETF