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

["Susan Hares" <[e-mail]>]

Donald: 

 

Excellent set of changes. Just 2 small nits to catch. 

 

A small nit: 

In sentence: (up to a configurable number of timese (DirQueryRetries, see Section/ 

/timese/times/

 

In section on Method 2, Medium Specificity.

 

For each unit of data (IA APPsub-TLV Address Set [IA]) held by the server and each address about which a negative response was sent, record when the last response sent with that positive response data will expire and when the last negative response will expire; the records are retained until such expiration

 

/until such expiration/until both expirations occur./ 

 

Sue Hares 

 

-----Original Message-----
From: Donald Eastlake [mailto:[e-mail]] 
Sent: Monday, December 21, 2015 11:55 PM
To: Susan Hares
Cc: [e-mail]; [e-mail]; Linda Dunbar; Radia Perlman; Liyizhou; Igor Gashinsky
Subject: Re: Shepherds review of draft-directory-assist-mechanisms

 

Hi Sue,

 

Thanks for these extensive comments. See below:

 

On Fri, Oct 2, 2015 at 3:46 PM, Susan Hares < <mailto:[e-mail]> [e-mail]> wrote:

> This is a shepherd’s review for:

> 

>  <http://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mech> http://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mech

> anisms/

 

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   <mailto:[e-mail]> [e-mail]