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

Donald Eastlake <d3e3e3@gmail.com> Thu, 02 March 2017 22:45 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900EF12941D; Thu, 2 Mar 2017 14:45:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 jXttIP1lpv-M; Thu, 2 Mar 2017 14:45:42 -0800 (PST)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CB41293F8; Thu, 2 Mar 2017 14:45:42 -0800 (PST)
Received: by mail-io0-x22f.google.com with SMTP id f84so62767707ioj.0; Thu, 02 Mar 2017 14:45:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.107.48.142 with SMTP id w136mr185419iow.16.1488494741443; Thu, 02 Mar 2017 14:45:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.215 with HTTP; Thu, 2 Mar 2017 14:45:25 -0800 (PST)
In-Reply-To: <CAF4+nEHcuMbxYCJvpQSmLrvUqcSvqAXBOfndW42O0ZpjX1-DGA@mail.gmail.com>
References: <148460788762.22588.13989856834598298736.idtracker@ietfa.amsl.com> <CAF4+nEHcuMbxYCJvpQSmLrvUqcSvqAXBOfndW42O0ZpjX1-DGA@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 2 Mar 2017 17:45:25 -0500
Message-ID: <CAF4+nEFb=TVPO2JBx2Q_7tPgymVydAKW4mOSD_PifPDT6_jzwQ@mail.gmail.com>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/Qmvylf9SUUSfjh1Vj6KsEOup9vw>
Cc: "trill-chairs@ietf.org" <trill-chairs@ietf.org>, draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG <iesg@ietf.org>, "shares@ndzh.com" <shares@ndzh.com>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [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
Precedence: list
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: 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.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Mon, Jan 16, 2017 at 9:57 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
> Hi Spencer,
>
> Thanks for your thorough review. See below
>
> On Mon, Jan 16, 2017 at 6:04 PM, Spencer Dawkins
> <spencerdawkins.ietf@gmail.com> wrote:
>>
>> Spencer Dawkins has entered the following ballot position for
>> draft-ietf-trill-directory-assist-mechanisms-11: No Objection
>>
>> ----------------------------------------------------------------------
>> 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.
>
> 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
>  d3e3e3@gmail.com