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

[Donald Eastlake <[e-mail]>]

Hi Sue,

On Mon, Jan 4, 2016 at 8:35 PM, Susan Hares <[e-mail]> wrote:

> 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/
>
OK.

> 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./
>
It is a bit ambiguous to convolve the two cases... These are really two
different kinds of records. So I think maybe the text should be

For each unit of data (IA APPsub-TLV Address Set [IA]) held by the server,
record when the last response sent with that positive response data will
expire. In addition record each address about which a negative response was
sent by the server and when the last such negative response will expire.
Each such record of a positive or negative response is discarded upon
expiration.

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


> -----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 <[e-mail]> wrote:
>
> > This is a shepherd’s review for:
>
> >
>
> > 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  [e-mail]
>