Re: [manet] Warren Kumari's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT)

I think having people directed to the list regarding questions of
implimentations is completely appropriate.

Justin Dean

On Thu, May 11, 2017, 11:45 AM Jiazi Yi <ietf@jiaziyi.com> wrote:

> Hi,
>
> <snip>
>
>
> "Although with existing experience, multiple paths can be obtained even
> with such partial information,  the calculation might be impacted,
> depending on the MPR selection algorithm used." - I don't understand the
> "with existing experience", and this sentence is a fragment. I suspect
> that removing " with existing experience," would make this cleaner, but I
> don't really understand what you are trying to say…
>
>
> Does this sound better:
>
> Although multiple paths can be obtained even with such partial information
> based on existing experience, the calculation might be impacted depending
> on
> the Multi-Point Relay (MPR) selection algorithm used.
>
>
> I think, "Experience has shown that multiple paths can be obtained
> even with such partial information, however, depending on the
> Multi-Point Relay (MPR) selection algorithm used, the calculation
> might be impacted”.
>
>
> Yes.
>
> I'm not quite sure what you mean by: "calculation
> might be impacted" - perhaps "suboptimal results may be obtained"? Or
> something.
>
>
> It’s the disjointness of the paths calculated. We will clarify it in the
> text also.
>
> <snip>
>
> 5.1:
> "CUTOFF_RATIO   The ratio that defines the maximum metric of a path
> compared to the shortest path kept in the OLSRv2 Routing Set. For
> example, the metric to a destination is R_metric based on the
> Routing Set." - I don't understand what the last sentence is trying to
> say.
>
> "CUTOFF_RATIO MUST be greater than or
>     equal to 1.  Note that setting the value to 1 means looking for
>     equal length paths, which may not be possible in some networks."
> -- surely setting it to 2 (or any other number) will also end up
> looking for paths which might not be possible?
> E.g:
>       ┌──┐  ┌──┐  ┌──┐  ┌──┐
> ┌────▶│R1│─▶│R2│─▶│R3├─▶│R4│─────┐
> │     └──┘  └──┘  └──┘  └──┘     ▼
> ┌───┐            ┌──┐            ┌───┐
> │ S │───────────▶│R6│───────────▶│ D │
> └───┘            └──┘            └───┘
>
>
> Yes. This is intentional: to avoid having too much variance between
> multiple
> paths obtained.
>
>
>
> Yup, but if set to 2, you might also not be able to find a path that
> works, so I think you need to remove: "Note that setting the value to
> 1 means looking for equal length paths, which may not be possible in
> some networks." -- or perhaps, "Setting the number low makes it less
> likely that additional paths will be found -- for example, setting it
> to 1 will only consider equal length paths" ? (I don't feel strongly
> about any of this)
>
>
> Yeah, this would be better. thanks.
>
> <snip>
>
>
>
> 9.  Configuration Parameters
> "the users of this protocol
>  are also encouraged to explore different parameter setting in various
> network environments, and provide feedback."  -- where?
>
>
> Hmmm… I didn’t quite get the question. You meant where to provide the
> feedback? There is contact information of the authors in the draft, and
> apparently, the mailing list is the right place also. If you want, we can
> call it out explicitly in the draft.
>
>
>
> Yup, that would be great -- perhaps "and provide feedback to the MANET
> WG <insert list name>"
> ID Guidlines contains:
>
> "It is strongly recommended that the draft include a notice (with
>   email address) of where comments should be sent.  For example:
>
>      "Comments are solicited and should be addressed to the working
>      group's mailing list at ___@______ and/or the author(s)."
> "
> -- perhaps just copy that.  Actually, chairs, do you want this (don't
> want to clutter up your list).
>
>
> I’m fine with the proposed text, unless the chairs are explicitly against
> it ;)
>
> Again, thanks very much for the review and the comments!
>
> regards
>
> Jiazi
>
>
>
>
>
> 12.  "IANA Considerations
>  This section adds one new Message TLV, allocated as a new Type
>  Extension to an existing Message TLV."
> -- this section seems to be missing some important information, like
> which registry this updates Message Type 7 in.
>
>
> The registry is "Message TLV Types” specified in
> https://tools.ietf.org/html/rfc7631
> We will add related information in the new revision.
>
>
> Win!
>
>
> best
>
> Jiazi
>
>
> Awesome, thank you for addressing all these...
>
> W
>
>
>
>
>
> Nits:
> S1.1:
>
> "Because the packet drop is normally bursty in a path" -- "Because packet
> drops on a path are normally bursty"...
>
> "Other than general experiences including the protocol specification and
> interoperability with base OLSRv2 implementations, the experiences in the
> following aspects are highly appreciated:"
> s/ experiences including/ experiences, including / (grammar)
> s/ the experiences / experiences / (grammar)
>
> "Although with existing experience,  multiple paths can be obtained even
> with such partial information,  the calculation might be impacted,
> depending on the MPR selection algorithm used."
> s/Although with existing experience/Although, with existing experience/
> (grammar)
>
> "In scenarios where the length of the source routing header is critical,
> the loose source routing can be considered."
> s/ the loose source /  loose source /
>
> "for  example, the paths with lower metrics (i.e., higher quality) can
> transfer more datagrams compared to paths with higher metrics." -- nit:
> many people (perhaps incorrectly) associate 'datagram' with 'UDP' - you
> might want to clarify (or just say packet)
>
> S3:
> "MP-OLSRv2 is designed for networks with dynamic topology by avoiding
> single route failure." - this makes it sound like it was *designed* by
> avoiding single route failure.
>
> "in IPv4 networks the interoperability is achieved by using loose source
> routing header;" - in IPv4 networks interoperability is achieved using
> loose source routing headers;" (or "by using the loose...")
>
> S4:
> "The reactive operation is local in the router" - "local to the router"
>
>
> S5.1:
> "All the intermediate routers MUST be included in the source routing
> header, which makes the number of hops to be kept a variable."
> -- I don't understand how the "the number of hops to be kept" is "a
> variable"; this makes it sound like I can set the number of hops to be
> kept. Perhaps you meant "a variable number of hops" or "the number of
> hops changes"?
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf
>
>