Re: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)

Donald Eastlake <> Thu, 02 March 2017 22:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 900EF12941D; Thu, 2 Mar 2017 14:45:44 -0800 (PST)
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 jXttIP1lpv-M; Thu, 2 Mar 2017 14:45:42 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44CB41293F8; Thu, 2 Mar 2017 14:45:42 -0800 (PST)
Received: by with SMTP id f84so62767707ioj.0; Thu, 02 Mar 2017 14:45:42 -0800 (PST)
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=fnLWeMx4JfAk50qx54PL7eNOpN3704N/yuhe0KSPGZI=; b=lOOiw9jghkOvtAfC7vsrJt0goyF8yyUIRegIsZOYChmfckXGEveTsy+TEuFoYpabbn MUrcPQygklDXa2nrBdK3D944LS09c/rYOe83Plq92VQpvVFlSnNrhx9jJ69j6nk8acdu 8akc8/UMJ7igHgwaQmRjNHmNix0eb8UAf9aTBeVHj8RaVlhU0mjuO7jMlsbM2bmEIWfD JI6JL8q7nDUiwC+c+CWNlLdDhSZaY8SPCRzMPN4xjRmQ3WjQqsMQBVa8+aZrkUf6oAKn bB+DC7D3uhJfybuz5K5EsAdclp0Jxdfwy/OMegYyohjoTPA5SkeJlE994oeCVfO9NkWd 0E6w==
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=fnLWeMx4JfAk50qx54PL7eNOpN3704N/yuhe0KSPGZI=; b=rf5AXkmuME1g6MnEQc6hcLNQTXxuqpateinlruUj0ovyeglpDjRvTrXcnN8fYBxDCZ hwsHMtds0E56vgFEO3BvW8S6QkGkUG7nZ4m9sQyG8dUpOHpTTrbAiZL+THnCnfPlHQY8 tzVk538gH29KlwmFROfMy/4lOv2WWIKGSO/Xttgvjp6XyoWy7hVonP1ve1LKbPB/SNm9 i5ElCOX0vn0C6AIo7DPbe3LpdKEBRlohrd6+9VNZ2Cbj0eFWrVSypFV/DqS5qPQ9gfFY 6q/3XPhSxkS36Yof642ieqwoYaIaJDX7FujwSIjMPeEpd4dTtU374CaiCspnT3RVHjiO qHFw==
X-Gm-Message-State: AMke39mSMUXAjSaxKEaU/aJ5/iFn4BfKVPsTtREE7oqWt6Roe59DiHpVghB+cpCTpH7s4vwOOEaSTej1Bzaadw==
X-Received: by with SMTP id w136mr185419iow.16.1488494741443; Thu, 02 Mar 2017 14:45:41 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 2 Mar 2017 14:45:25 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Donald Eastlake <>
Date: Thu, 2 Mar 2017 17:45:25 -0500
Message-ID: <>
To: Spencer Dawkins <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>,, The IESG <>, "" <>, "" <>
Subject: Re: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Mar 2017 22:45:45 -0000

Hi Spencer,

Version -12 of this draft, which has just been posted, is intended to
resolve your comments.

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

On Mon, Jan 16, 2017 at 9:57 PM, Donald Eastlake <> wrote:
> Hi Spencer,
> Thanks for your thorough review. See below
> On Mon, Jan 16, 2017 at 6:04 PM, Spencer Dawkins
> <> wrote:
>> Spencer Dawkins has entered the following ballot position for
>> draft-ietf-trill-directory-assist-mechanisms-11: No Objection
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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.
> It should probably say "It might have learned that information from
> the directory or could query the direction if it does not already know
> it."  because it could be that either (1) it has been pushed to it by
> a Push Directory or (2) it could have pulled it from a Pull Directory
> and cached it.
>> 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?
> Not quite. It could be de-anthropomorphised and made more precise by
> saying something like "A Push Directory advertises when it both is
> configured to be a directory having complete information and has
> actually pushed all the information it has."
>> 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.
> This propagation time, as you might expect, depends on network
> topology.  The worst possible time for a network with a large number
> of TRILL switches could be impractically long.  Yet, in a richly
> connected data center or Internet exchange with reasonably high
> bandwidth links, one second would be plenty of time.  In this
> specification, the time in the time for "The Time Condition" as
> specified in Section 2.3.2, page 11 and is, indeed, PushDirTimer. It
> defaults to twice the CSNP time, which is related to the ESADI link
> state consistency time scale and is pretty conservative. It might be
> good to add some forward pointers to the places where there is this
> "enough time" wording.
>> 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.
> OK
>> 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").
> Yes, the first occurrence of the word "the" should be deleted.
>> 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?
> Any feature that needs TRILL ES-IS needs to say so. TRILL ES-IS is
> specified in Section 5 which enumerates in its first paragraph the
> only existing use of TRILL ES-IS (Pull Directory hosting on and use by
> end stations) and the two anticipated uses of TRILL ES-IS (the
> trill-directory-assisted-encap and trill-smart-endnodes drafts).
> Probably the first and second paragraphs of Section 5 could be
> re-organized a bit to clarify this.
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA