[trill] Spencer Dawkins' No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)
"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Mon, 16 January 2017 23:04 UTC
Return-Path: <spencerdawkins.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 A46A712985B; Mon, 16 Jan 2017 15:04:47 -0800 (PST)
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.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148460788762.22588.13989856834598298736.idtracker@ietfa.amsl.com>
Date: Mon, 16 Jan 2017 15:04:47 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/Mdj9Nc02PKl3JBpIrtt-sTU7qyQ>
Cc: trill-chairs@ietf.org, draft-ietf-trill-directory-assist-mechanisms@ietf.org, shares@ndzh.com, trill@ietf.org
Subject: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 16 Jan 2017 23:04:48 -0000
Spencer Dawkins has entered the following ballot position for draft-ietf-trill-directory-assist-mechanisms-11: 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-directory-assist-mechanisms/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In this text, It might learn that information from the directory or could query the directory if it does not know. is "learning information from the directory" different from "querying the directory"? My apologies for not knowing TRILL well. I found this text, A Push Directory also advertises whether or not it believes it has pushed complete mapping information for a Data Label. to be odd ("directories believe things?"), and I'm wondering what that belief would be based on. If a Push Directory has pushed all the information it's currently storing, is that what's being described here? Or does this mean something else? In section 2.3.1, there are several states that refer to "enough time for propagation" - for example, Active Completing <S4>: Same behavior as the Active state except that the server responds differently to events. The purpose of this state is to be sure there has been enough time for directory information to propagate to subscribing edge TRILL switches before the Directory Server advertises that the information is complete. Is it possible to provide a pointer or reference that describes how "enough time" is calculated? I'm not sure whether this is referring to PushDirTimer in Section 2.7 or something else. It's a nit, but I think this text, TRILL switches, whether or not they are a Push Directory server, should be something like TRILL switches, whether or not they are Push Directory servers, - there's a numbering mismatch. I think this text, Thus, there is commonly a small window during which the an RBridge using directory information might either (1) drop or unnecessarily flood a frame as having an unknown unicast destination or (2) encapsulate a frame to an edge RBridge where the end station is not longer connected when the frame arrives at that edge RBridge. is garbled (somewhere around "during which the an RBridge"). In this text, Support of TRILL ES-IS is generally optional for both the TRILL switches and the end stations on a link but may be required to support certain features. can you give any guidance to the reader on how to know whether TRILL ES-IS support is required for a feature?
- [trill] Spencer Dawkins' No Objection on draft-ie… Spencer Dawkins
- Re: [trill] Spencer Dawkins' No Objection on draf… Donald Eastlake
- Re: [trill] Spencer Dawkins' No Objection on draf… Donald Eastlake