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

Abdussalam Baryun <abdussalambaryun@gmail.com> Fri, 19 May 2017 12:20 UTC

Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB91E12947B; Fri, 19 May 2017 05:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 mh43Bwq6JMAF; Fri, 19 May 2017 05:20:38 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 43C8E128D64; Fri, 19 May 2017 05:14:43 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id f55so56202641qta.3; Fri, 19 May 2017 05:14:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZM2h/+nmJXLHYvj/HVfvzwFIkE43plliI5Tr9nIe+3w=; b=eqMhEFs/yXdWDIDsk0O3DtWIhxE8qJ3vkjpT3wY15jImsnaooUO8cQtHhqUjTF/88r bTESDwRXYnruu2dVTsxaJ9S9YmgLClvlzgn4NXsmcVSf5svc6bmpEWSXwKfsRjQccfvY 81CSXbv3qaX+bRP067adE9TItlCY4RKAUMqDt9ochCM4Y1nejkYTHcVqeNnSnavPRYDD ZTgYIZnC5oOW9e4IPY0826iduCACMJ3lUty2QXyWTr/jmcmtQgn2Rs8CbYJRqp3bUEbT czX58jPZ1pJNlhdQHf9ES/0ksUYNUWYRk3kNYlXS+v9Bcxb2i6YGPMMm+TjcG55zLGU6 6txg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZM2h/+nmJXLHYvj/HVfvzwFIkE43plliI5Tr9nIe+3w=; b=KcfDTNmdd89+WhMDVmEmIVkmLx89ocupfGPc0SCY7F6z0SiNfFFhXJIWR+u4ezAMZl C1GGdc5sDQLkxCqZr4s+fr+ou5DPQmDbmpr1rYkrxlgmgxk+c/npPfERjv6FdGzVHNIU 2+ATEzThwndow4jGMZ9yzxEd5qcEhXfcm7GgkZFJcOVEhoEoJdWwTn+PKQholhnvZ96W imSG3OZ64SXp8nTA5Z+NiP/RNlrnFFZTdwr0i35uimPBYFdX1+LAsxOnR8pMuca8h4Bg LR5N5CnhQWBbuUX6BhYRIq/R7R8OwnZbLkgxm9VxZnbTmnM7xVhofZYMXfDwhtjslL+Y TIUg==
X-Gm-Message-State: AODbwcBvmSHAaLaRyeEm0m5/uiq4TIANKsMk/kxesVkP06yg4Xnzb8OH 5iS0Oe0TLtYvmpuWCgok+CtfRGoFyNpI
X-Received: by 10.200.47.83 with SMTP id k19mr9997713qta.254.1495196082341; Fri, 19 May 2017 05:14:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.88.52 with HTTP; Fri, 19 May 2017 05:14:41 -0700 (PDT)
In-Reply-To: <CAHw9_i+Q897kB-3Spjf_uVMAVEYz7VD7aNMOR1oXFCCgQL80Sw@mail.gmail.com>
References: <149443053917.11242.9983663008416318557.idtracker@ietfa.amsl.com> <6F3176EF-9AC5-44A2-A3C2-DC2E0529CB35@jiaziyi.com> <CAHw9_iKhMB+PY6HH=Z8QsScga+wH_vn3r3NovXWZq8sEbF8Q+g@mail.gmail.com> <B9B55008-5FF4-4FB0-BCF4-3449FA6CC76A@jiaziyi.com> <CA+-pDCch1JedQS6hLGhqejJQaYUuDsG7XhCNrDKe0Bx=_KcEQQ@mail.gmail.com> <CAHw9_i+Q897kB-3Spjf_uVMAVEYz7VD7aNMOR1oXFCCgQL80Sw@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
Date: Fri, 19 May 2017 14:14:41 +0200
Message-ID: <CADnDZ8_P-LHeD-3tfC=JgLG-hFDhtLDcbG8UXBfhCKQ3uFwJvQ@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: Justin Dean <bebemaster@gmail.com>, manet <manet@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-manet-olsrv2-multipath@ietf.org, Mobile Ad-hoc Networks Working Group <manet-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="001a1136fa785b90be054fdf77c7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/H_KGjDuLS23kA2_nuM1rGDQdumk>
Subject: Re: [manet] Warren Kumari's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 May 2017 12:20:42 -0000

Yes it is a good idea to add the list address, but need IESG/wg-chairs work
harder to maintain acknowledgements/replies to any participants that send
to the list/draft.

AB

On Mon, May 15, 2017 at 5:09 PM, Warren Kumari <warren@kumari.net> wrote:

> Great. Thanks all...
>
> W
>
> On Sun, May 14, 2017 at 4:51 PM, Justin Dean <bebemaster@gmail.com> wrote:
> > 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
>
>
>
> --
> 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
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>