Re: [manet] draft-ietf-olsrv2-multipath-09

[Stan Ratliff <[e-mail]>]

Chris,

The 1-week WGLC was predicated on the thought that we had basically
concluded - that your issues had been addressed, and therefore, what was
needed was a "once-over" check. Apparently, that's not the case.

Having said that, the desire is not to set unreasonable timeframes, but to
make progress, and produce a quality document. So, if the conversation and
revisions take more than the 1-week period, so be it. Let's get it right.

Regards,
Stan


On Mon, Jun 13, 2016 at 5:53 PM, Christopher Dearlove <
[e-mail]> wrote:

> I’v looked at draft -09, and I think it still needs work. I have some
> followups from previous comments, some new comments, and some editorial
> comments that I didn’t get round to making last time. And this may not be
> complete, but I’m up against the too short one week limit set. (I’m afraid
> we just aren’t getting given the necessary time in this group. And I seem
> to be the only one commenting.)
>
> Section 1.1, fifth bullet, “very important”. To whom? Not justified. And
> should make it clear this applies to FEC applied across packets, not within
> a packet.
>
> Page 4, third bullet, why discuss hop count? OLSRv2 is not hop count
> limited, it’s not even an explicit special case.
>
> Page 5, second bullet. How does FEC help with packet re-ordering?
>
> Page 5, fourth bullet, add “with” after “experiment”.
>
> Page 6, first paragraph. I still disagree with characterising as low data
> rate links. At most the protocol multiplies capacity by a small factor, not
> the orders pf magnitude that link capacities span.
>
> RFC0791, I think omitting the 0 is usual style.
>
> Section 4, first paragraph, not requires, perhaps uses.
>
> The reactive approach in particular has interactions with IP. The
> requirements this protocol imposes on IP need to be documented. (This point
> was made about AODVv2, it applies here - the interactions aren’t identical,
> but need to be specified.
>
> MAX_SRC_HOPS - explain 11.
>
> CUTOFF_RATIO - why strictly greater than one? Should work equal to one.
>
> Section 6.1.1, last word, messages.
>
> Section 7, capitalise Base.
>
> Section 7.1. No need for OLSR in element names, never used anywhere else.
> Usual OLSRv2 style is SR_time without valid. Also SR_orig_addr (we are
> careful about usage).
>
> Delete “it” in multiple element definitions after -
>
> PT_… Explain n. Note that n may not be same in all cases.
>
> PT_… What about hop count? Elsewhere in OLSRv2 we record that as well (e.g
> Routing Set).
>
> Various places, delete “the” before Section.
>
> Still no discussion of advertised addresses, should they be encouraged in
> TC messages. Except SR required TC messages, see previous proposal on
> strongly recommending against them. I can’t see that added.
>
> Section 8.2 Setting what should be SR_orig_addr, add address after
> originator.
>
> A major omission is discussion of expiry of new Tuples without expiry
> times. If proactive you can (but don’t) discuss when supporting sets
> change. If reactive it’s rather a mess (a reason I dislike the reactive
> mechanism). When to discard? When to recreate? If dependent on packet flow
> then that’s another interaction with IP to document - and implement.
>
> You could when acting reactively forward by usual means in all cases while
> waiting.
>
> The actual packet forwarding by round-robin is an IP process, not this
> protocol. Needs to not be buried in 8.4. And if it’s an IP process, why
> mandate exactly how it’s used?
>
> Page 12, second bullet. How is this information known? There’s no
> signalling that includes it.
>
> Capitalise all instances of Tuple for consistency.
>
> Page 13. Brutally is not really appropriate language.
>
> Section 8.5.2, I haven’t had time to review this.
>
> Section 9, delete track after experimental.
>
> Section 9, related to not reviewing 8.5.2, it’s not clear how the final
> bullet points arise. And what does “tend to” mean?
>
> Section 10, not reviewed.
>
> Appendices, not reviewed.
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>