Re: [trill] my thoughts ->Re: draft-ietf-trill-directory-assist-mechanisms-02 - 2 week WG (5/29 to 6/12)

Donald Eastlake <d3e3e3@gmail.com> Tue, 09 June 2015 01:27 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 B273F1A036B for <trill@ietfa.amsl.com>; Mon, 8 Jun 2015 18:27:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.551
X-Spam-Level: *
X-Spam-Status: No, score=1.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, J_CHICKENPOX_22=0.6, 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 4j3lxmLprbiw for <trill@ietfa.amsl.com>; Mon, 8 Jun 2015 18:27:52 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 50F561A0078 for <trill@ietf.org>; Mon, 8 Jun 2015 18:27:52 -0700 (PDT)
Received: by oiha141 with SMTP id a141so2966669oih.0 for <trill@ietf.org>; Mon, 08 Jun 2015 18:27:51 -0700 (PDT)
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=os43OL4mIGUxiW1A+B+ls6NfZ+32qywr0lsMT4gkRfk=; b=WF4xK1jgXXfae8AuePgz69Yrx0OG9ITnlqJD2ABDulyV8nRGSaYza3t4coUrrUUiyF PyiyROaFh9ZYQf7eTWR0dHbPo3mEH8MJfF+ne2iyeiIa1aSsaLXWSlVFTBgjk2o9fH8r AgMykA9SF3wWqXI7vq6nFX336o8cAJ49nZkVhQXS8cX0uh7VZ7rqM5eXiwY3YyyBqyFC 676O7KiFsAr5DnFkv2sRnTzC44gcQN4UTlfDUka2OpRxGNj1mTsnkQwSBT12edkZ/Kf2 ZHAfvh66fDMTLUOPCaDqerGC7LVRV5Tdap2NVMnVgoKoe8Iigy4IuCXs3IOvpjm7JHUX 8yQQ==
X-Received: by 10.202.188.139 with SMTP id m133mr15887884oif.73.1433813271503; Mon, 08 Jun 2015 18:27:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.153.2 with HTTP; Mon, 8 Jun 2015 18:27:35 -0700 (PDT)
In-Reply-To: <201506032339.t53NdowU057351@skyhighway.com>
References: <02c001d09a08$6f42f7a0$4dc8e6e0$@ndzh.com> <4A95BA014132FF49AE685FAB4B9F17F657C4D699@dfweml701-chm> <201506032339.t53NdowU057351@skyhighway.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 8 Jun 2015 21:27:35 -0400
Message-ID: <CAF4+nEFZncbmE7wawAWf_YYfSOOwLgUHDk3EirNa5C5e7seEkg@mail.gmail.com>
To: gayle noble <windy_1@skyhighway.com>
Content-Type: multipart/alternative; boundary=001a113dca20b8ea2205180baa75
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/6HwjadW4BvEE9wOgO-x6nnP9oJo>
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] my thoughts ->Re: draft-ietf-trill-directory-assist-mechanisms-02 - 2 week WG (5/29 to 6/12)
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: <http://www.ietf.org/mail-archive/web/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, 09 Jun 2015 01:27:57 -0000

Hi Gayle,

Thanks for your corrections and questions. I'm fine with your suggested
changes 1-20.

The existence of both the "Query Message" and the "QUERY Record" data
structures is a bit confusing. The Query Message contains from zero to 15
QUERY Records. I'll think about the best way to clarify this.

And I think your suggested wording change in reference to priority ordering
of Push Directory servers is good.

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

On Wed, Jun 3, 2015 at 7:39 PM, gayle noble <windy_1@skyhighway.com>; wrote:

>              TRILL: Edge Directory Assist Mechanisms
>         <draft-ietf-trill-directory-assist-mechanisms-02.txt>
>
> corrections::
>
> 1.   page 7 first complete sentence on this page
> ["Push Directories" should be "Push Directory servers" and "copies of the
> directory that will be pushed." doesn't make sense in the context of the
> rest of the sentence.]
> (as written)
> If the Push Directories for a Data Label are configured consistently with
> the same N and at least N servers are available, then N copies of the
> directory that will be pushed.
> (maybe should be ??)
> If the Push Directory servers for a Data Label are configured
> consistently with the  same N and at least N servers are available, then N copies
> of that directory will be pushed.
> -----------------------------------------------------
>
> 2.   page 7 second paragraph second sentence
> [This sentence has a period after "APPsub-TLV." which is followed by a
> trailing part of the sentence after the period which seems to be a repeat
> of the information before "APPsub-TLV."]
> (as written)
> This priority is treated as an unsigned integer where larger magnitude
> means higher priority and is in its ESADI Parameter APPsub-TLV. means
> higher priority.
> (should probably be written by breaking into two sentences)
> This priority is treated as an unsigned integer where larger magnitude
> means higher priority. This priority appears in its ESADI Parameter
> APPsub-TLV.
> -------------------------------
>
> 3.   page 8 first paragraph second sentence
> ["and representing the state" does not make sense. Should this be "and
> "represents the state" ?]
> (as written)
> The name of each state is followed by a symbol that starts and ends with
> an angel bracket and representing the state.
> (should be???)
> The name of each state is followed by a symbol that starts and ends with
> an angel bracket and represents the state.
> ---------------------------------------
> 4.   page 8 last paragraph
> [This needs a few commas around "that the directory is no longer
> complete"  and "stop" should be "stops"]
> (as written)
> Going Stand-By <S6>: The same behavior as Active except that it
>      responds differently to events. The purpose of this state is to be
>      sure that the information that the directory is no longer complete
>      has enough time to propagate to edge TRILL switches before the
>      Directory Server stop advertising updates to the information.
> (should be)
> Going Stand-By <S6>: The same behavior as Active except that it
>      responds differently to events. The purpose of this state is to be
>      sure that the information, that the directory is no longer complete,
>      has enough time to propagate to edge TRILL switches before the
>      Directory Server stops advertising updates to the information.
>
> ----------------------------------------------------------------------------
>
> 5.   page 9 first paragraph second sentence
> [A few commas around "that the directory is no longer complete" needed]
> (as written)
> The purpose of this state is to be sure that the information that the
> directory is no longer complete has enough time to propagate to edge
> TRILL switches before the Directory Server might stop advertising updates
> to the information.
> (I'd write)
> The purpose of this state is to be sure that the information, that the
> directory is no longer complete, has enough time to propagate to edge
> TRILL switches before the Directory Server might stop advertising updates
> to the information.
>
> ----------------------------------------------------------------------------------
>
> 6.   page 10 First paragraph second sentence
> ["data reachable" repeated twice]
> (as written)
> This is determined by the server finding that it is priority K among the data
> reachable data reachable Push Directory servers (where highest priority
> is 1), it is configured that there should be N copies pushed, and K is
> greater than N.
> (should be)
> This is determined by the server finding that it is priority K among the data
> reachable Push Directory servers (where highest priority is 1), it is
> configured that there should be N copies pushed, and K is greater than N.
> -------------------------------------------------------------
>
> 7.   page 12 first paragraph
> ["for" should be "from"]
> (as written)
> Push Directory mappings can be distinguished for other data distributed
> through ESADI because mappings are distributed only with the Interface
> Addresses APPsub-TLV [IA] and are flagged in that APPsub-TLV as being Push
> Directory data.
> (should be)
> Push Directory mappings can be distinguished from other data distributed
> through ESADI because mappings are distributed only with the Interface
> Addresses APPsub-TLV [IA] and are flagged in that APPsub-TLV as being Push
> Directory data.
> --------------------------------------------------------------------
>
> 8.   page 12 sixth paragraph
> ["have" should be "has" as it is referring to a single switch]
> (as written)
> Condition 2 is necessary because a client TRILL switch might be just
> coming up and receive an EASDI LSP meeting the requirement in condition 1
> above but have not yet received all of the ESADI LSP fragment from the
> Push Directory server.
> (should be)
> Condition 2 is necessary because a client TRILL switch might be just
> coming up and receive an EASDI LSP meeting the requirement in condition 1
> above but has not yet received all of the ESADI LSP fragment from the
> Push Directory server.
>
> ----------------------------------------------------------------------------
>
> 9.   page 13 last paragraph last sentence
> ["alreayd" should be spelt "already"]
> (as written)
> Because the data from a secondary server will necessarily be at least a
> little less fresh than that from a primary server, it is RECOMMENDED that
> the re-  originated secondary server data be given a confidence level of
> one less than that of the data as received from the primary (or unchanged
> if it is alreayd of minimum confidence).
> (should be)
> (as written)
> Because the data from a secondary server will necessarily be at least a
> little less fresh than that from a primary server, it is RECOMMENDED that
> the re-  originated secondary server data be given a confidence level of
> one less than that of the data as received from the primary (or unchanged
> if it is already of minimum confidence).
>
> ----------------------------------------------------------------------------
>
> 10. page 14 third paragraph last sentence
> ["Errors returns can be sent" should either be "Error returns" or "Errors
> returned" and "Errors can be returned" reads a whole lot better]
> (as written)
> Errors returns can be sent for queries or updates as described in Section
> 3.5.
> (I think it should be)
> Errors can be returned for queries or updates as described in Section
> 3.5.”
>
> --------------------------------------------------------------------------------
>
> 11. page 15  Flags: second sentence
> ["Flags" is plural "is" is singular. So "is" should be "are" and "meaning"
> should be "meanings"]
> (as written)
> Flags whose meaning is not specified are reserved, MUST be sent as zero,
> and MUST be ignored on receipt.
> (should be)
> Flags whose meanings are not specified are reserved, MUST be sent as
> zero, and MUST be ignored on receipt.
>
> -----------------------------------------------------------------------------------
>
> 12. Page 16 Sequence Number first sentence
> ["opaque" means "impervious to light, so that images cannot be seen
> through it" I think what is wanted is "*identifying*" defined in RFC 791]
> (as written)
> An opaque 32-bit quantity set by the TRILL switch sending a request or
> other unsolicited message and returned in every corresponding reply or
> acknowledgement.
> (probably should be)
> An *identifying* 32-bit quantity set by the TRILL switch sending a
> request or other unsolicited message and returned in every corresponding
> reply or acknowledgement.
> --------------------------------------------------------
>
> 13. Page 18 second to the last sentence
> ["sent" is past tense. "sentence is in present tense. So it should be
> ""send"]
> (as written)
> If a TRILL switch is not capable of handling partial responses to queries
> with multiple QUERY Records, it MUST NOT sent a Request Message with more
> than one QUERY Record in it.
> (should be)
> If a TRILL switch is not capable of handling partial responses to queries
> with multiple QUERY Records, it MUST NOT send a Request Message with more
> than one QUERY Record in it.
>
> -------------------------------------------------------------------------------------
>
> 14. page 19 first sentence
> ["Message result" I think it should be "Message results"]
> (as written)
> A Pull Directory Query Message result in a Pull Directory Response
> Message as described in Section 3.2.2.1.
> (I think it should be)
> A Pull Directory Query Message results in a Pull Directory Response
> Message as described in Section 3.2.2.1.
>
> ------------------------------------------------------------------------------
> 15. page 22  RARP:  second sentence
> [I'd add the words "as described" before "above" or omit "above"]
> (as written)
> If the ar$op field is ares_op$REQUEST, the frame is handled as an ARP
> above.
> (I'd write)
> If the ar$op field is ares_op$REQUEST, the frame is handled as an ARP as
> described above.
>
> ---------------------------------------------------------------------
>
> 16. page 22 last sentence
> [This sentence is missing a comma and also missing some words to make the
> end make sense.
> First thought:: "there may still be brief periods of time when directory
> information has changed"
> second thought:: "but cached information a pull clients has"
> third thought not complete:: "not yet been updated or expunged."
> It is like the "has" from the end of the second thought, is being auto
> reused???  Also "clients" is plural but "a" refers to a singular. What if I
> rephrase this ???? :::]
> (as written)
> In all cases, there may still be brief periods of time when directory
> information has changed but cached information a pull clients has not yet been
> updated or expunged.
> (I'd write)
> In all cases, there may still be brief periods of time when directory
> information has changed, but information a pull client has cached has not
> yet been updated or expunged.
>
> ----------------------------------------------------------------------------------
> 17. page 25 section 3.3.1. Update Message Format first sentence
> ["Message with the with differences" an extra "with"]
> (as written)
> An Update Message is formatted as a Response Message with the with
>   differences described in Section 3.3 above and the following:
> (should be)
> An Update Message is formatted as a Response Message with the differences
> described in Section 3.3 above and the following:
> ------------------------------------------------------------------------
>
> 18.   page 32 second paragraph second sentence
> [ Add comma after "That is" and "Lable" should be "Label"]
> (as written)
> That is the Push Model is used for some Data Labels or addresses within a
> Data Lable while the Pull Model is used for other Data Labels or
> addresses within a Data Label.
> (should be)
> That is, the Push Model is used for some Data Labels or addresses within
> a Data Label while the Pull Model is used for other Data Labels or
> addresses within a Data Label.
>
> -------------------------------------------------------------------------------------
>
> 19. page 32 third paragraph third sentence
> ["for management interface" reads real rough. It says thee is one
> interface "management interface" which is not what I think is meant. It
> would read smoother if "interface" was "interfacing" which covers any
> management stuff done]
> (as written)
> For hosts in other Data Labels that only communicate with external peers
> occasionally for management interface, the mapping entries for those
> VLANs should be pulled down from directory when the need comes up.
> (I'd write)
> For hosts in other Data Labels that only communicate with external peers
> occasionally for management interfacing, the mapping entries for those
> VLANs should be pulled down from directory when the need comes up.
>
> ----------------------------------------------------------------------------
>
> 20. page 35   6.1 ESADI-Parameter Data Extensions first sentence
> ["assigned" is past tense. I think this is a request to have it assigned
> so it should be present tense]
> (as written)
> Action 1: IANA will assigned a two bit field [bits 1-2 suggested] within
> the ESADI-Parameter TRILL APPsub-TLV flags for "Push Directory Server
> Status" (PDSS) and will create a sub-registry in the TRILL Parameters
> Registry as follows:
> (should be)
> Action 1: IANA will assign a two bit field [bits 1-2 suggested] within
> the ESADI-Parameter TRILL APPsub-TLV flags for "Push Directory Server
> Status" (PDSS) and will create a sub-registry in the TRILL Parameters
> Registry as follows:
>
> -----------------------------------------------------------------------------------
>
> Confusion
>
>
> 1.      page 28/29 description of error fields
> The text states:
> ERR values 1 through 126 are available for encoding Request or Update
> Message level errors.
> ERR values 128 through 254 are available for encoding QUERY or RESPONSE
> Record level errors
> Then the fields are noted
> (as written)
>       Err    Meaning
>      -----   -------
>          0    (no error)
>
>          1    Unknown or reserved Query Message field value
>          2    Request Message/data too short
>          3    Unknown or reserved Update Message field value
>          4    Update Message/data too short
>      5-126    (Available for allocation by IETF Review)
>        127    Reserved
>
>        128    Unknown or reserved QUERY Record field value
>        129    QUERY Record truncated
>        130    Address not found
>        131    Unknown or reserved RESPONSE Record field value
>        132    RESPONSE Record truncated
>      133-254  (Available for allocation by IETF Review)
>        255    Reserved
> Just be aware this is VERY confusing as one who is not a guru at this
> would think it would be::
>       Err    Meaning
>      -----   -------
>          0    (no error)
>
>         1     Unknown or reserved Request Message field value
>          2    Request Message/data too short
>          3    Unknown or reserved Update Message field value
>          4    Update Message/data too short
>      5-126    (Available for allocation by IETF Review)
>        127    Reserved
>
>        128    Unknown or reserved QUERY Record field value
>        129    QUERY Record truncated
>        130    Address not found
>        131    Unknown or reserved RESPONSE Record field value
>        132    RESPONSE Record truncated
>      133-254  (Available for allocation by IETF Review)
>        255    Reserved
>
>
> ===============
> total confusion::
>
> 2.   page 7 second paragraph second sentence
> A sentence is written
> "This priority is treated as an unsigned integer where larger magnitude
> means higher priority"
> Based on everything I can find, " larger magnitude", means larger number.
> Thus 2 is a larger magnitude then 1.
> However in paragraph 3 the third sentence it says :
> "If a Push Directory server is configured to believe that N copies of the
> mappings for a Data Label should be pushed and finds that it is number K in
> the priority ordering (where number 1 is highest priority and number K is
> lowest), then if K is less than or equal to N the Push Directory server
> is Active. If K is greater than N it is Stand-By."
>
> (It would be less confusing to us nubies if written)
> “If a Push Directory server is configured to believe that N copies of the
> mappings for a Data Label should be pushed and finds that it is Kth in the
> priority ordering (where the first is highest priority and the last is
> lowest), then if K is less than or equal to N the Push Directory server
> is Active. If K is greater than N it is Stand-By."
>
>
> -----------------------------------------------------
>
>
>
>
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
>