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

[Donald Eastlake <[e-mail]>]

Hi Spencer,

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

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]


On Mon, Jan 16, 2017 at 9:57 PM, Donald Eastlake <[e-mail]> wrote:
> Hi Spencer,
>
> Thanks for your thorough review. See below
>
> On Mon, Jan 16, 2017 at 6:04 PM, Spencer Dawkins
> <[e-mail]> 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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]