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

Donald Eastlake <d3e3e3@gmail.com> Tue, 17 January 2017 02:57 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 95AF01294B8; Mon, 16 Jan 2017 18:57:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no 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 qu0R_1Mudydm; Mon, 16 Jan 2017 18:57:55 -0800 (PST)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 86FE4129675; Mon, 16 Jan 2017 18:57:55 -0800 (PST)
Received: by mail-it0-x229.google.com with SMTP id c7so86903222itd.1; Mon, 16 Jan 2017 18:57:55 -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=Myfk9j9XLwZQwGERHwt+wUqvp/crpJiz7tCe4zDXY4s=; b=JdPhiKPjLfopImIM5wXIBXRAykcTH6D2/iVUibRwqm7P+z8T2Ur8zKs2Nx4CpnOCJk NgiP1EvqXwjYnJiha/9gR15AnTxMD67jQ3ttTN1gnzS5UG+1GtLmTNQ7cBl29/3PAfEF +dSQ/pLkmdeE1s7c2qo5Z8DTZPLnhYjW4c9Xhy1E+Fn2umnT0fCjIbH0is/BeoYPuLsF 5ZiHMlNlZlm38aJFsQ/X3eXaS9d8vpq00rV6VI/ZCw3b2yWuhXaO1GnZ0o3egMTVN78j 8uiQBEOvJYNyF/68SYesMZljqfStVi+0lhkNevAAyiuKftAn9GJ2jIyqCU3TAxGzbi8m PgXw==
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=Myfk9j9XLwZQwGERHwt+wUqvp/crpJiz7tCe4zDXY4s=; b=PMY1dwJz80LiGr0/hDaX156jr/mjCsi5u4wIfg6xchHKFHHxCWSoqe7PnNEROGvFB8 uRuo6FhNLf8w42M3J9hCKSlo0Yp/SDrskXgaVqYX5xXHoS9Y4zHrQniNzP5jNQEV7u78 SXLFfp+YSKsS+Wa63b8d1PRtQDz3BPUx+dN3YRZEHEp9B/ikPHi2onI8/rF6eRN0MVvi jZzUMRwYCJzgvk1SY/gC8oOsatl1flqTNda/uiQxvnhLhN34wsu3+r4HKpzKiBgJwtTK iI8NyLVtSPRThGEUXIxW6FI3HYF85cSHgvlrAD5pBp1wqWmx2To4WQQsEBziYOznN502 Ic/A==
X-Gm-Message-State: AIkVDXJCYf5mB6QTlo7kAf7jwRCNHH/mopIzpe4OnhWaFsRcIFsQiQoruFGPWIAzmcaPlhny7KCVn9nxYIpY1A==
X-Received: by 10.36.3.73 with SMTP id e70mr16884979ite.14.1484621874615; Mon, 16 Jan 2017 18:57:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.41.72 with HTTP; Mon, 16 Jan 2017 18:57:39 -0800 (PST)
In-Reply-To: <148460788762.22588.13989856834598298736.idtracker@ietfa.amsl.com>
References: <148460788762.22588.13989856834598298736.idtracker@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 16 Jan 2017 21:57:39 -0500
Message-ID: <CAF4+nEHcuMbxYCJvpQSmLrvUqcSvqAXBOfndW42O0ZpjX1-DGA@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/YGsCAgXTLiYQObZk6ylOqbNJtUY>
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: Tue, 17 Jan 2017 02:57:56 -0000

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