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, 04 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 > >
- [trill] Shepherds review of draft-directory-assis… Susan Hares
- Re: [trill] Shepherds review of draft-directory-a… Donald Eastlake
- Re: [trill] Shepherds review of draft-directory-a… Susan Hares
- Re: [trill] Shepherds review of draft-directory-a… Donald Eastlake
- Re: [trill] Shepherds review of draft-directory-a… Susan Hares
- Re: [trill] Shepherds review of draft-directory-a… Donald Eastlake