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

Donald Eastlake <d3e3e3@gmail.com> Tue, 05 January 2016 04:17 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD3C1AD0BF; Mon, 4 Jan 2016 20:17:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tkufYkowapu; Mon, 4 Jan 2016 20:17:38 -0800 (PST)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9471AD0A1; Mon, 4 Jan 2016 20:17:38 -0800 (PST)
Received: by mail-oi0-x22f.google.com with SMTP id y66so268029459oig.0; Mon, 04 Jan 2016 20:17:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LnWCcHppgn1qA/0ZABL7eNLkXffpDpByDfb5xmlS8xA=; b=k8C96irsmfyvzUfRH6VqHOppcwdxmZgfwxEBAn5WFBkVAx9GTPz/alDW5SVPqgYgQ4 etOmR2ybq4Z0NqhsuPmuP/S3l+9DUQKdU7RMMkoaMUYOLBxNt9LA3zRRS7tx0bwpUejX /jfU66LHRjCZYHRujMolMx8hnjXzsXaa2F1NmWjGjtjldJ9pVoF2Pm4AyBU6qJU7S6TF 4kc6BAygk98ONlOPfKkYfxqHOPnyk+7EU8dz8/mBIBE+0HwdPfYiH/JAxI0KsC6zJKUI +c7cSWSDPAyTy4NiKblW2lkdhhbCcJur3a130ts1/209rmnYlPIPKnRWCv9HNqA61Ycg 2VsQ==
X-Received: by 10.202.203.73 with SMTP id b70mr59805859oig.108.1451967457984; Mon, 04 Jan 2016 20:17:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.157.161 with HTTP; Mon, 4 Jan 2016 20:17:23 -0800 (PST)
In-Reply-To: <01ff01d1476a$845678a0$8d0369e0$@ndzh.com>
References: <001601d0fd4b$107bd5b0$31738110$@ndzh.com> <CAF4+nEHxmkWnoa89e32_s9vHMeQipoFwO4J6yW4eH0A_DAFj9w@mail.gmail.com> <014d01d14759$6d6545b0$482fd110$@ndzh.com> <CAF4+nEHEfoErK3-7pF7Y7nndncN=z=ChapOVh6eEJG+n0S+yBw@mail.gmail.com> <01ff01d1476a$845678a0$8d0369e0$@ndzh.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 4 Jan 2016 23:17:23 -0500
Message-ID: <CAF4+nEHX69eoQtxtUezxMBx6y-6m=0fwguioYRfrANGbVw2bLQ@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=001a1134f5848f060005288e847d
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/ML1z3LYFOHgBAb5LHH8Mr7bNsP0>
Cc: draft-ietf-trill-directory-assist-mechanisms@ietf.org, Radia Perlman <Radia@alum.mit.edu>, Linda Dunbar <linda.dunbar@huawei.com>, "trill@ietf.org" <trill@ietf.org>, Liyizhou <liyizhou@huawei.com>, Igor Gashinsky <igor@yahoo-inc.com>
Subject: Re: [trill] Shepherds review of draft-directory-assist-mechanisms
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2016 04:17:44 -0000

HI Sue,

On Mon, Jan 4, 2016 at 10:38 PM, Susan Hares <shares@ndzh.com> wrote:

> Donald:
>
>
>
> Your wording on the 2nd Nit is definitely better.   Do you want to make
> this change? After I get the updated draft, this draft is ready to send to
> IESG.
>

Thanks, I can just post a quick update version tonight.

Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


> Sue
>
>
>
>
>
> *From:* Donald Eastlake [mailto:d3e3e3@gmail.com]
> *Sent:* Monday, January 04, 2016 10:24 PM
>
> *To:* Susan Hares
> *Cc:* trill@ietf.org;
> draft-ietf-trill-directory-assist-mechanisms@ietf.org; Linda Dunbar;
> Radia Perlman; Liyizhou; Igor Gashinsky
> *Subject:* Re: Shepherds review of draft-directory-assist-mechanisms
>
>
>
> Hi Sue,
>
>
>
> On Mon, Jan 4, 2016 at 8:35 PM, Susan Hares <shares@ndzh.com> 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   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com
>
>
>
> -----Original Message-----
>
> From: Donald Eastlake [mailto:d3e3e3@gmail.com]
> Sent: Monday, December 21, 2015 11:55 PM
> To: Susan Hares
> Cc: trill@ietf.org; draft-ietf-trill-directory-assist-mechanisms@ietf.org;
> 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 <shares@ndzh.com> 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   +1-508-333-2270 (cell)
>
> 155 Beaver Street, Milford, MA 01757 USA  d3e3e3@gmail.com
>
>
>
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
>