Re: [trill] Shepherds review of draft-directory-assist-mechanisms

[Donald Eastlake <[e-mail]>]

Hi Sue,

Thanks for these extensive comments. See below:

On Fri, Oct 2, 2015 at 3:46 PM, Susan Hares <[e-mail]> wrote:
> This is a shepherd’s review for:
>
> http://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/

This review is of Version -03. Version -04 has been posted in response.

> Shepherd’s review:
>
> Status:  Technically sound, but needs minor technical editing done before
> sending to IESG.
>
>
> One thing the authors need to consider is whether all the knobs specified in
> the draft are documented carefully.
>
> The shepherd believes at least 5 knobs were not document.

I have added Section 3.9 listing and giving info on Pull Directory
knobs and added Section 2.6 listing Push Directory knos and added
appropriate references to them and other changes elsewhere...


> Minor Technical: (needs clarifying before goes to IESG).
>
>
> #1 - Section 2.3.2 text:
>
> The activate condition in sentence:
>
> “For example, the Push Directory server is configured that 2 copies should b
> epushed and finds that it is priority 1 or 2 among the Push Directory
> servers it can see.”
>
> Note: “can see” does not correctly specify what is happening.  I suspect
> that the appropriate response is “Push Director servers is receiving
> messages from”.  However, the paragraph needs the technical clarification.

"can see" meant was visible in its ESADI link state database for the
Data Label in question. Each Push Directory server must joining ESADI
for each Data Labe whose addresses it is pushing (flooding as ESADI
FS-LSPs) and it also pushes an ESADI parameters TLV by which it
advertises itself to all other Push Directory servers for that Data
Label. This is explained at the beginning of Section 2.2. I believe
the wording specifying the "active condition" and the "stand-by
condition" has been clarified.

> #2 - Section 2.4 –
>
> Additional Push details needs revising if the APPsub-TLV is revised.

A revision to draft-ietf-trill-ia-appsubtlv has been posted but I do
not think it requires any change here.

> #3 – Section 3.2.2.1
>
> Text: “Responses are sent with the same Data Label and priority as the Query
> Message to which they correspond except that the Response Message priority
> is limited to be not more than a configurable value”.
>
> Comment: It would be good to have a set of values which specify what the
> configured value is.  Is this a max-message-response query?  If so, we need
> a place to collect these timers if there are not being specified in the
> section.  If it is being specified in the section, then I missed it.  Help
> me by specify what the configured value is.

I haved added symbolic names for this and various other configuration
parameters and a new Section 3.9.

> #4 – top of page 25 starting with the text “A Pull Directory server” – You
> need to specify the knob
>
> Textual suggestions toward the knob
>
> //it has sent an Update message and received a corresponding Acknowledge
> Message or tit hs sent a configurable number of updates at configurable
> interval which default to 3 updates with 100 milliseconds apart/
>
> To
>
>  /it has either: a) sent an Update message and received a corresponding
> Acknowledge Message, or b) it has sent a configurable number of updates at a
> configurable rate (set by [knob name]).   The [knob name] defaults to a
> setting of 3 updates 100 milliseconds apart. /

See previous response above.

> #5 – page 34 –
>
> It is not clear why the If Flooded Immediately goes from 2 > 0 > 1 > 1
>
> Please add something that helps me understand this. Or tell me why I’m crazy
> to think this.

I have added a Note. This is because in IEEE Std 802.1Q, priority 1 is
lower than the default prority 0. so the priorities from low to high
are 1, 0, 2, 3, 4, 5, 6, 7.

> #6 – IANA  - Has OKed the IANA section
>
> ======================
>
> Editorial:
>
> #1 Section: 2.2, p. 7 paragraph 2
>
> p. 7 – good to reference in paragraph 3 beginning “For each Data label it
> can serve” the section 2.3 below.

OK.

> #2 Section 2.2.3 text:
>
> The activate condition in sentence: “For example, the Push Directory
> server is configured that 2 copies should be pushed and finds that
> it is priority 1 or 2 among the Push Directory servers it can see.”

Not sure what you meant above but I tried to make this sentence more
readable.

> #3 Section 3.2.1 – Pull Directory Query Message Format
>
> Page 18: Query address – you give MAC address and IP address as examples.
> If you have some other time of address, we should really have an example.
> In fact it would be useful to have examples to improve the technical
> clarity.

I added a couple of things and a bit more motivation...

> p. 18 – paragraph at bottom of page
>
> /If no response is received to a Pull Directory Query Message within a
> timeout configurable in milliseconds that default to 100, the query message
> should be re-transmitted within the same Sequence Number up to a
> configurable number of times that defaults to three. /
>
>  To
>
> /If no response is received to a Pull Directory Query Message within a
> pull-query timeout period, then the query message should be re-transmitted
> with the same sequence number (up to pull-query-retransmit-limit). The
> pull-query timeout is a configurable knob that defaults to 100 ms.  The pull
> query retransmit-limit is a configurable knob which defaults to three.

I have made changes along these lines but with different configuration
variable names and with references to new Secton 3.9 summarizing such
configuration variables.

> #4 spelling on page 21 – top of page
>
> From /“message level error code in it, then the the REPONSE”/
> To /“message level error code in it, then the RESPONSE"/

OK.

> Change: /ecosing/ enclosing/
> Change: /Repose/ Response/

OK.

> IN the next paragraph: /Multiple RESPONSE Records can appear in a Response
> Message with the same Index if the answer to a QUERY Record/
>
> To
> /Multiple RESPONSE Records can appear in a Response Message with the same
> Index if the message is an answer to the QUERY Recrord/

OK.

> #4 section 3.2.2.2 Pull Directory Forwarding
>
> Second sentence of paragraph:
>
> /In these cases, if the information is not in the directory the provided
> frame is forwarded by the Pull Directory server as a multi-destination TRILL
> Data packet if the FL Flag in the Query message was one./
>
> To
>
> /In these cases, if the information sought is not in the directory and the
> FL flag in the query message was one, the provided frame is forwarded by the
> Pull Directory server as a multi-destination TRILL Data packet. /

OK.

>  #5 – section 3.2.2.2
> Location: MacDA:
> /fame/frame

OK.

> #6 – 3.3. cache consistency
>
> In the second paragraph, I would recommend that you break after the first
> sentence and provide the text at the top of page 23.
>
> Here’s the example:
>
> A Pull Directory server MUST maintain one of the following three sets of
> records in order of increasing specificity:
>
> 1)      Retaining more specific records such as given in method 3 below,
> 2)      Retaining less specific records such as given in method 1 below,
> 3)      ????
>
> Method 1: (include text)
>             Pro: Put the pro/con by the method from above
>             Con:
>
> Method 2: (Include text)
>             Pro:
>             Con:
>
> Method 3:  ((including text)
>             Pro:
>             Con:
>
> Put the pro/con by the method.

OK. I did something along those lines.

> Pull Directory issues:
> Include the pull directory test (p. 23-24)

Not quite sure what you mean.

> #7 – page 23
>
> Bottom:  If method 1 (the crudest method)
> Suggestion: find another word or phrase beside “crude”

Replaced with "the least detailed method,"

> #8 – page 24 – top
>
> Paragraph beginning “If method 2 is being followed:
>
> Delete /Such message are somewhat similar to the method 1 flooded flush
> update and are also sent a RBridge Channel messags with an ..”
>
> Either break into two sentences or delete “such messages are someone
> similar” or provide more details.

OK. Deleted text as you auggested.

> #9  - page 24 bottom
> From: /unsolicited response are compared to the addresses about which/
> To; /unsolicited responses are compared to the addresses which/

I changed "about which" to "for which". I think it reads better.

> #10 – section for 2a, 2b. 2c., 2d in section 3.3
>
>                 Suggest you use a format of:
>
> Situation: Description of situation
> Action: Action occurring in the step

I reformatted somewhat along those lines although I didn't use the
exact format you suggest...

> #11 – 3.3.1 Update format
>
> /Update messages are initiated by a Pull Directory Server.  The Sequence
> number space is controlled by the original Pull Directory server, [1] and
> different from Sequence number spaced used in a Query and the corresponding
> Response that are controlled by the querying TRILL switch./
>
> At [1] suggest you end the sentence /Pull Directory server. This [name]
> Sequence number space  is different than from the Sequence number.
>
> Otherwise it is a bit confusing.

OK.

> #12 – 3.3.2 Acknowledge Message format (p. 26)
> Paragraph 1
> From: /It is also formatted as a Response Message but the Type is set to 4. /
> To: /It is formatted as a Response Message but the Type is set to 4./

OK.

> #12 /paragraph 2/
> Remove /essentially/ - it seems to serve no purpose.

OK.

> #13 Section 3.5 Pull Directory Hosted on an End Station.  (p., 27)
> This section could really be clarified by adding a picture..

I have added a Figure and a paragraph of text to accompany the figure.

This lead me to discover that the draft previously had only one
captioned Figure that was labeled "Figure 2". :-) So I changed that
earlier Figure to be Figure 1 and labeled the new one as Figure 2.

> #14 – Section 3.5 page 28
>
> Nickname section
> From:
> /The proxy copies this from the ingress nickname when mapping a Query or
> Acknowledge Message to a native form.  It also takes this from a native
> Response Message or a Update Message to be used/
> To:
> /The proxy copies this nickname from the ingress nickname when mapping a
> Query or Acknowledge Message to a native form.  It also takes this nickname
> from a native Response Message or a Update Message to be used/

OK.

> #15 – section 3.5. p. 28 section Data Label
> From: /RBridge Channel Pull Directory messages appears here/
> To  /RBridge Channel Pull Directoy Messages appears in this field/

OK.

> From: /This might appear/
> To: /This database might appear/

Actuslly /This Data Label might appear/

> #16 page 29 section 3.6 paragraph top of page
>
> /probably were not even looked at by the Pull Directory server and would
> provide no information in the Response or Acknowledge Message so they are
> omitted and the Count field is set to zero in the Response or
> Acknowledgement Message./
>
> /probably were not even looked at by the Pull Directory Server and would
> provide no additional information in the Response or Acknowledge Message.
> Therefore, this section with the Query Response or Update Message or header
> is omitted and the Count field is set to zero in the Response or
> Acknowledgement Message/.

OK.

> p. 29.  Paragraph 2/3 – “a Acknowledge Message/ an Acknowledge
>message/

OK.

> #17 – section 3.8
> From /But, with Push and Pull/
> To: /However with Push and Pull/

OK.

> From: /it may cause increased link utilization/
> To: /it may cause increased link utilization due to traffic/

I went a bit further and said /it may cause increased link utilization
by some sending multi-destination traffic where it is not needed./


In the process of reviewing and resolving these comments, I made some
editorial improvements and also notedvthe following:
- There was no summary of added configuration parameters for Push
Directory servers, so I added a Section 2.6 for that.
- The Push Directory section did not say what to do if the configured
priority of two Push Directory servers tied. I added that the tie is
broken by their System IDs.
-  Etc.

Thanks again for the comments. I believe they have significantly
improved the draft.

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