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 [email protected] On Mon, Jan 16, 2017 at 9:57 PM, Donald Eastlake <[email protected]> wrote: > Hi Spencer, > > Thanks for your thorough review. See below > > On Mon, Jan 16, 2017 at 6:04 PM, Spencer Dawkins > <[email protected]> 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 > [email protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
