Re: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00

"Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> Fri, 03 January 2014 10:25 UTC

Return-Path: <chris.dearlove@baesystems.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EE61AD66E for <manet@ietfa.amsl.com>; Fri, 3 Jan 2014 02:25:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.102
X-Spam-Level:
X-Spam-Status: No, score=-4.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] autolearn=ham
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 FRxQAz2EgwrA for <manet@ietfa.amsl.com>; Fri, 3 Jan 2014 02:25:08 -0800 (PST)
Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id E53E71ADF5B for <manet@ietf.org>; Fri, 3 Jan 2014 02:25:07 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.95,597,1384300800"; d="jpg'145?scan'145,208,217,145"; a="401842915"
Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 03 Jan 2014 10:25:00 +0000
X-IronPort-AV: E=Sophos; i="4.95,597,1384300800"; d="jpg'145?scan'145,208,217,145"; a="36987863"
Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 03 Jan 2014 10:25:00 +0000
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.67]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Fri, 3 Jan 2014 10:24:59 +0000
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: Jiazi Yi <yi.jiazi@gmail.com>, MANET IETF <manet@ietf.org>
Thread-Topic: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00
Thread-Index: AQHO3s9g+LbWKHriwUKQlQmUlSpPcppzHc2w
Date: Fri, 03 Jan 2014 10:24:59 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D401D6259@GLKXM0002V.GREENLNK.net>
References: <5280BB8E.6000906@gmail.com> <5280BC3E.7000101@gmail.com>
In-Reply-To: <5280BC3E.7000101@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.62.6]
Content-Type: multipart/related; boundary="_004_B31EEDDDB8ED7E4A93FDF12A4EECD30D401D6259GLKXM0002VGREEN_"; type="multipart/alternative"
MIME-Version: 1.0
Subject: Re: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 03 Jan 2014 10:25:12 -0000

I failed to respond to this earlier, but my files have the unpublished RFC 6966 as having the changed title (starting with "Rationale") compared to the -04 draft, I presume (my recollection is incomplete) at the request of the RFC Editor. Thus I believe the reference is actually correct, but we can confirm that when RFC 6966 is published.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com<mailto:chris.dearlove@baesystems.com> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Jiazi Yi
Sent: 11 November 2013 11:15
To: MANET IETF
Subject: Re: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00


*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
And one nit:

In the reference, we have

   [RFC6966-to-be]
              Clausen, T., Dearlove, C., and P. Jacquet, "Rationale for
              the Use of Link Metrics in the Optimized Link State
              Routing Protocol Version 2 (OLSRv2)", RFC 6966, TBD 2013.

I suppose the name of the draft is

  Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale

http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-04 ?

Jiazi


[cid:image001.jpg@01CF086E.0DD39AB0]
Jiazi Yi<mailto:yi.jiazi@gmail.com>
11 Nov 2013 12:12
Hi,

I had a review of draft-dearlove-manet-olsrv2-rmpr-optimization-00. Here are some comments (or some of them, I would rather call questions :)

1. In Section 4: Routing MPR Selection
...
then x_1 to x_n may be removed from the set of routing MPRs, if selected.
...

The first note: I think we should use RFC2119 term "MAY" here?
In fact, this is the part that confuses me most. As the only "action" described in the draft, the use of "may" without further explanation when this action should be taken or not is too vague. In the end of the section, another "RECOMMENDED" is used. Therefore, if I put them together, it is something like "It is RECOMMENDED that one MAY do foo, bar..."

2.  If x_1, x_2 ... x_n are the largest set with corresponding y_1, y_2, ... y_n. Should we check all the subsets {x_i} of x_1, ... x_n with the criteria

d1(x_0) + d2(x_0,y_1) + ... + d2(x_m-1,y_m) < d1(x_m) for m belong to subset of x_1, ... x_n?

If so, we probably will have a lot combinations to check in a dense network. If not, the criteria seems to be too harsh to be actually "triggered"?


3. Should this be applied to all types of metrics? A potential affects of this draft is that, we can probably have more "hops" around the neighborhood of the original router, i.e., there is higher possibility of interference. In some of metrics, the interference is not much considered (because it is hard to measure). Will it be a problem if we introduce more transmission in some scenarios?

4. We have a "Willingness" value to "represents the router's willingness to be selected as an MPR." Should this need to be considered also? What about if x_0 has low willingness, while the others x_1, ... x_n have higher willingness?

5. In some scenarios, we probably want to have certain redundancy in MPR in some lossy scenarios?

sincerely

Jiazi


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************