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

[Henning Rogge <[e-mail]>]

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)
<[e-mail]> wrote:
> 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:
>
> 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:
>
> 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.
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>