Subject: [manet] AD Review of draft-ietf-manet-olsrv2-dat-metric-06

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 5 Oct 2015 21:12:01 +0000

Hi!

I just finished reading this draft.  Thank you for the background and history.

I identified some Major issues that should be easy to fix.  But in general I found the document relatively easy to read and understand.  Once you address the comments (and post an update, as needed) for the Major items I will start the IETF Last Call.

Thanks!

Alvaro.

Major:

  1.  What are the parameters of this experiment?  Being an Experimental document, there should be some guidance as to what type of information wants to be collected, what type of topologies should be used, etc..to eventually declare the experiment a success.  This information can be used later to change the track and (for example) use it to move the DAT into the Standards Track.
  2.  Section 9.2. (Requirements for using DAT metric in OLSRv2 implementations)
     *   What happens to packets that don't meet these requirements?  I'm assuming that they're just not used to calculate the DAT, is that true?  Is it ok if some packets on a link meet the requirements and others don't?
     *   The INTERVAL_TIME TLV doesn't have to be in every HELLO (according to rfc6130), and Section 9.4 accounts for that already.  So it looks like that is not really a requirement.
  3.  There is some rfc2119 language in Section 9.3. (Link Loss Data Gathering) that is not clear.
     *   "For each incoming [RFC5444] packet, additional processing SHOULD be carried out after the packet messages have been processed as specified in [RFC6130] and [RFC7181]."  Which additional processing?  Are you just referring to what is specified later in this section?  Please be specific.
     *   "[RFC5444] packets without packet sequence number MUST NOT be processed in this way by this metric."  I'm guessing here you also are referring to what's specified in the rest of the section, right?
  4.  Even though this document doesn't formally (because it is Experimental) Update rfc5444, rfc6130 and rfc7181, it would be a good idea to include a section (maybe around Section 5) that summarizes the changes/updates done here.

Minor:

  1.
In Section 2. (Terminology), "diff_seqno(new, old)" is defined.  However, Section 9.3 uses "seq_diff" instead.
     *   Section 3. (Applicability Statement): the references to OLSRv2 seems to not be correct.
  2.  Section 6. (Protocol Parameters)
     *   This section starts by talking about "two constants", and then listing "these constants", but the list actually has 4 parameters.  Section 7 also seems to talk about constants.  Should these two sections be merged into one??
     *   s/DAT_MEMORY_LENGTH  - Queue length…within the queue are used to calculate the cost of the link./DAT_MEMORY_LENGTH  - Queue length…within the queue length are used to calculate the cost of the link.
  3.  In Section 6.1. (Recommended Values) the recommended value for DAT_REFRESH_INTERVAL is 1; the first paragraph says that "mobile networks might require shorter DAT_REFRESH_INTERVAL".  The only thing lower than 1 is 0; would that mean that in a mobile network the recommendation is to continuously recalculate the metric?
  4.  References:
     *   RFC3626, RFC7182 and RFC7183 can be Informative.
  5.  Do you want to reference the appendixes (B, C and D) somewhere in the main text?

Nits:

  1.  Introduction: s/OLSR networks gathered since the publication of OLSR/OLSR networks gathered since its publication
  2.  The DLEP reference is out of date.
  3.  Section 4:
     *   s/dijkstra/Dijkstra
     *   "…already gathered link loss data…"  A reference to Section 9 would be nice.
  4.  Appendix A.
     *   B.A.T.M.A.N. Reference?
     *   "consists of 400 routers (around 600 routes)"  400 or 600?
  5.  Idnits identifies some line spacing issues, please take a look.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 9 Oct 2015 15:44:13 +0200

Hi

and thank you for the long review. I will see that I post a new
revision of the draft next week and/or come back with a few questions
for clarification.

Henning Rogge

On Mon, Oct 5, 2015 at 11:12 PM, Alvaro Retana (aretana)
<[email-masked]> wrote:
> I identified some Major issues that should be easy to fix.  But in general I
> found the document relatively easy to read and understand.  Once you address
> the comments (and post an update, as needed) for the Major items I will
> start the IETF Last Call.
>
> Thanks!
>
> Alvaro.
>
>
> Major:
>
> What are the parameters of this experiment?  Being an Experimental document,
> there should be some guidance as to what type of information wants to be
> collected, what type of topologies should be used, etc..to eventually
> declare the experiment a success.  This information can be used later to
> change the track and (for example) use it to move the DAT into the Standards
> Track.
> Section 9.2. (Requirements for using DAT metric in OLSRv2 implementations)
>
> What happens to packets that don't meet these requirements?  I'm assuming
> that they're just not used to calculate the DAT, is that true?  Is it ok if
> some packets on a link meet the requirements and others don't?
> The INTERVAL_TIME TLV doesn't have to be in every HELLO (according to
> rfc6130), and Section 9.4 accounts for that already.  So it looks like that
> is not really a requirement.
>
> There is some rfc2119 language in Section 9.3. (Link Loss Data Gathering)
> that is not clear.
>
> "For each incoming [RFC5444] packet, additional processing SHOULD be carried
> out after the packet messages have been processed as specified in [RFC6130]
> and [RFC7181]."  Which additional processing?  Are you just referring to
> what is specified later in this section?  Please be specific.
> "[RFC5444] packets without packet sequence number MUST NOT be processed in
> this way by this metric."  I'm guessing here you also are referring to
> what's specified in the rest of the section, right?
>
> Even though this document doesn't formally (because it is Experimental)
> Update rfc5444, rfc6130 and rfc7181, it would be a good idea to include a
> section (maybe around Section 5) that summarizes the changes/updates done
> here.
>
>
> Minor:
>
> Section 3. (Applicability Statement): the references to OLSRv2 seems to not
> be correct.
>
> Section 6. (Protocol Parameters)
>
> This section starts by talking about "two constants", and then listing
> "these constants", but the list actually has 4 parameters.  Section 7 also
> seems to talk about constants.  Should these two sections be merged into
> one??
> s/DAT_MEMORY_LENGTH  - Queue length…within the queue are used to calculate
> the cost of the link./DAT_MEMORY_LENGTH  - Queue length…within the queue
> length are used to calculate the cost of the link.
>
> In Section 6.1. (Recommended Values) the recommended value for
> DAT_REFRESH_INTERVAL is 1; the first paragraph says that "mobile networks
> might require shorter DAT_REFRESH_INTERVAL".  The only thing lower than 1 is
> 0; would that mean that in a mobile network the recommendation is to
> continuously recalculate the metric?
> References:
>
> RFC3626, RFC7182 and RFC7183 can be Informative.
>
> Do you want to reference the appendixes (B, C and D) somewhere in the main
> text?
>
>
> Nits:
>
> Introduction: s/OLSR networks gathered since the publication of OLSR/OLSR
> networks gathered since its publication
> The DLEP reference is out of date.
> Section 4:
>
> s/dijkstra/Dijkstra
> "…already gathered link loss data…"  A reference to Section 9 would be nice.
>
> Appendix A.
>
> B.A.T.M.A.N. Reference?
> "consists of 400 routers (around 600 routes)"  400 or 600?
>
> Idnits identifies some line spacing issues, please take a look.
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>