Subject: [manet] Questions regarding draft-ietf-manet-olsrv2-19

From: "Kirchhoff, Jonathan" <[email-masked]>
Date: Mon, 20 Jan 2014 17:21:27 +0000

Dear MANET group members,

I'm currently working on an implementation of MPRs according to
draft-ietf-manet-olsrv2-19, and I have come across some statements in
the draft that seem unclear.

I'd really appreciate it if someone could comment on these points.

1.) Flooding MPR selector state

In section 8.1 (page 31), it is stated that the flooding MPR selector
state is to be recorded in the link set as L_mpr_selector. The other
states (Flooding MPR; Routing MPR / MPR selector) are recorded per
neighbor.

What is the reason for having L_mpr_selector in the link set?

Since the MPR selection is recorded per-neighbor, this variable might
intuitively be part of the neighbor set as well.

2.) Message forwarding decision

--- Quote from section 14.3 (Page 47):
3.  Otherwise if the sending address matches (taking account of any
address prefix) any network address in an L_neighbor_iface_addr_list of
a Link Tuple in the Link Set for the receiving OLSRv2 interface that has
L_status = SYMMETRIC and whose corresponding Neighbor Tuple has
N_mpr_selector = true, then:
---

This part refers to the variable N_mpr_selector, which records the
routing MPR selector state. If I'm not mistaken, this should refer to
L_mpr_selector instead.

3.) Notation of neighbor graph sets

--- Quote from section 18.2 (Page 72):
A Neighbor Graph is a structure defined here as consisting of sets N1
and N2 and some associated metric and willingness values. Elements of
set N1 represent willing symmetric 1-hop neighbors, and elements of set
N2 represent addresses of a symmetric 2-hop neighbor.

A Neighbor Graph has the following properties:

o  It contains two disjoint sets N1 and N2.
---

To me, the the notion 'disjoint' suggests that N2 denotes 'strict
symmetric 2-hop neighbors' (as in OLSRv1), which are not symmetric 1-hop
neighbors at the same time. However, on the same page it reads:

--- Quote from section 18.2 (Page 72):
For some elements y in N2 there is an associated metric d1(y) > 0.
---

To my understanding, d1(y) being defined implies that the same node is
reachable directly and is thus part of N1. In this case, the sets would
not necessarily be disjoint.
As far as I'm concerned, the remaining definitions make sense if the
sets are not required to be disjoint as well.

As mentioned, I'd be happy to receive some comments on this.

Thanks in advance!

Best regards
Jonathan Kirchhoff

-- 
Jonathan Kirchhoff, M.Sc.
Communication Systems (KOM)

Fraunhofer Institute for Communication, Information Processing and
Ergonomics FKIE

Institute of Computer Science 4 - University of Bonn

Friedrich-Ebert-Allee 144, 53113 Bonn, Germany
Phone +49 228 73-54204
[email-masked]

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 20 Jan 2014 17:45:02 +0000

1. This is probably largely historical, from a slightly different arrangement some versions back. Though it has the advantage of putting interface related decision information into a per interface set. But note that you are of course free to actually choose to organise your information however you choose in an implementation.

2.   Good catch, and nicely timely as we are doing edits with the RFC Editor right now and can add this to the list. Note that (see point above) this gets rid of the Neighbor Tuple here.

3. N1 and N2 are disjoint. If a node is both a 1-hop and 2-hop neighbour, it will be represented in both sets, but not by the same member. In fact when you look more closely, in N1 there is something representing a 1-hop neighbour (Neighbor Tuple), and 1-hop neighbours have all sorts of baggage, including multiple addresses (in principle). In N2 there's something representing a 2-Hop Tuple, which has a single (network) address. There could therefore be multiple entries in N2 corresponding to an entry in N1. Or of course an entry in N2 may have no corresponding entry in N1. (Correspondence will be if the Neighbor Tuple contains the address in the 2-Hop Tuple, which it may do for several 2-Hop Tuples.)

So the point of saying disjoint is to (try to) make it clear that even if elements correspond, they are different elements. It's easier that way. (Or in any case, what the authors proposed, and the WG didn't raise any objections to. But of course once again, an implementation can do what it likes.)

-- 
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
[email-masked] | 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

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Kirchhoff, Jonathan
Sent: 20 January 2014 17:21
To: [email-masked]
Subject: [manet] Questions regarding draft-ietf-manet-olsrv2-19

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

I'm currently working on an implementation of MPRs according to draft-ietf-manet-olsrv2-19, and I have come across some statements in the draft that seem unclear.

In section 8.1 (page 31), it is stated that the flooding MPR selector state is to be recorded in the link set as L_mpr_selector. The other states (Flooding MPR; Routing MPR / MPR selector) are recorded per neighbor.

Since the MPR selection is recorded per-neighbor, this variable might intuitively be part of the neighbor set as well.

--- Quote from section 14.3 (Page 47):
3.  Otherwise if the sending address matches (taking account of any address prefix) any network address in an L_neighbor_iface_addr_list of a Link Tuple in the Link Set for the receiving OLSRv2 interface that has L_status = SYMMETRIC and whose corresponding Neighbor Tuple has N_mpr_selector = true, then:
---

This part refers to the variable N_mpr_selector, which records the routing MPR selector state. If I'm not mistaken, this should refer to L_mpr_selector instead.

--- Quote from section 18.2 (Page 72):
A Neighbor Graph is a structure defined here as consisting of sets N1 and N2 and some associated metric and willingness values. Elements of set N1 represent willing symmetric 1-hop neighbors, and elements of set
N2 represent addresses of a symmetric 2-hop neighbor.

To me, the the notion 'disjoint' suggests that N2 denotes 'strict symmetric 2-hop neighbors' (as in OLSRv1), which are not symmetric 1-hop neighbors at the same time. However, on the same page it reads:

To my understanding, d1(y) being defined implies that the same node is reachable directly and is thus part of N1. In this case, the sets would not necessarily be disjoint.
As far as I'm concerned, the remaining definitions make sense if the sets are not required to be disjoint as well.

Thanks in advance!

Best regards
Jonathan Kirchhoff

Fraunhofer Institute for Communication, Information Processing and Ergonomics FKIE

Friedrich-Ebert-Allee 144, 53113 Bonn, Germany Phone +49 228 73-54204 [email-masked]
_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet

********************************************************************
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.
********************************************************************

---

From: "Kirchhoff, Jonathan" <[email-masked]>
Date: Mon, 20 Jan 2014 18:08:45 +0000

Dear Christopher,

many thanks for your quick response.

Best regards
Jonathan Kirchhoff

---

From: Henning Rogge <[email-masked]>
Date: Mon, 20 Jan 2014 19:18:33 +0100

On Mon, Jan 20, 2014 at 6:45 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> 2.   Good catch, and nicely timely as we are doing edits with the RFC
> Editor right now and can add this to the list. Note that (see point above)
> this gets rid of the Neighbor Tuple here.
>

I wonder if we should rename the "x_mpr_selector" variables into something
like "x_flooding/routing_mpr_selector" to make sure they cannot be mixed up
when implementing OLSRv2. It sounds like something that could be done in an
editor change because it will change nothing to the protocol but make the
description more foolproof.

Its not really that important, but it might be a good idea.

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 20 Jan 2014 19:02:32 +0000

I think I speak for the authors that we have no intention of doing this. It may be editorial, but it's been accepted up to now, through the whole process, and the likelihood of making an error would massively outweigh any possible advantage, even if we agreed on what.

-- 
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 20 Jan 2014, at 18:18, Henning Rogge <[email-masked]> wrote:
> 
>> On Mon, Jan 20, 2014 at 6:45 PM, Dearlove, Christopher (UK) <[email-masked]> wrote:
> I wonder if we should rename the "x_mpr_selector" variables into something like "x_flooding/routing_mpr_selector" to make sure they cannot be mixed up when implementing OLSRv2. It sounds like something that could be done in an editor change because it will change nothing to the protocol but make the description more foolproof.
>