Subject: [manet] I-D Action:draft-ietf-manet-olsrv2-11.txt

From: [email-masked]
Date: Tue, 20 Apr 2010 08:30:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title           : The Optimized Link State Routing Protocol version 2
	Author(s)       : T. Clausen, et al.
	Filename        : draft-ietf-manet-olsrv2-11.txt
	Pages           : 83
	Date            : 2010-04-20

This document describes version 2 of the Optimized Link State Routing
(OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 22 Apr 2010 13:15:06 +0200

On Tue April 20 2010 17:30:02 [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Mobile Ad-hoc Networks
> Working Group of the IETF.
> 
> 
One comment about the new OLSRv2 draft.

In section "15.2.2 Address Block TLVs" it's specified that routable originator 
IPs can be either used a single NBR_ADDR_TYPE tlv with value 3 (routable AND 
originator) or two NBR_ADDR_TYPE tlvs with value 1 (originator) and value 2 
(routable).

I think this two possibilities make parsing TCs more difficult and the 
specification more complex.

It would be better to allow only one NBR_ADDR_TYPE tlv (with value 0-3) or 
using two different tlvs, one for declaring a routable address and one for a 
originator address (both without value).

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 22 Apr 2010 16:05:42 +0100

I mostly agree. We have a suggested simplification of this (not
quite the same as yours, but similar) that we hoped to get into
this draft. Unfortunately pressure of work (for me) and Thomas
running into a problem meant that this (and a couple of other
things) didn't make it into this version of the draft, and we
felt it more important to get a draft out as the previous one
had expired, and it was this one now, or a longer delay.

Incidentally the current three-value version has been around
for 6 months, it was in the last draft too. But it was lower
down the "to do" list than things needed for consistency with
the latest NHDP, as what we have works, it just could be better.

What specific alternative am I suggesting? Actually all we need
is a single NBR_ADDR_TYPE TLV with two values (might as well
be 0 or 1) for non-originator and originator (the latter an
error if associated with a non-simple address). There's no
need to specify routable with a specific value for two reasons
(a) why include anything else with this TLV? (b) by specification
you can recognise routable addresses anyway.

We are undecided whether to tidy up these things in another
pre-metrics draft, or put them in when we put metrics in. The
deciding factor will be time-driven.

Incidentally I have written code that parses the current draft,
and even intelligently works out what the best combination of
NBR_ADDR_TYPE TLVs to send is. That's one reason I know it needs
simplifying!

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 22 April 2010 12:15
To: [email-masked]
Subject: Re: [manet] I-D Action:draft-ietf-manet-olsrv2-11.txt

Henning Rogge

********************************************************************
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: Henning Rogge <[email-masked]>
Date: Thu, 22 Apr 2010 17:23:02 +0200

> had expired, and it was this one now, or a longer delay.
Okay.

> you can recognise routable addresses anyway.
I think there might be a problem for pure relays, routers without a globaly 
routable IP (just a relay with linklocal IPs or something similar). How can 
the neighbors put this relay into their TCs without someone building a route 
towards it ?

> NBR_ADDR_TYPE TLVs to send is. That's one reason I know it needs
I just noticed it while reading the diff between the last two OLSRv2 drafts.

Henning Rogge

-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 22 Apr 2010 16:45:52 +0100

> the neighbors put this relay into their TCs without someone building a
route 

That's a good point. That might be why we have the current three
state case (it's been a while, I don't recall all the arguments)
and may be an argument to retain it.

Unfortunately that leads us down the route to where we currently
have it. The two TLVs suggestion is a cure worse than the disease,
because it disallows the case that's often most efficient - one
multivalue TLV covering all addresses. And if you want to write
simple code to send TC messages you can do just that - always
use a single TLV.

The current case however leaves the case where someone sends the
ORIGINATOR and ROUTABLE cases as two TLVs attached to the same
address (noting that those might be two different copies of the
same address). You basically then have the choices of parse as
what's obviously intended (and allows a different simple
implementation of always using two TLVs, one ORIGINATOR, one
ROUTABLE, that may overlap addresses sorted appropriately),
reject the message (failing the "be liberal in what you parse"
maxim) or leave unspecified (which we shouldm, and do, not do).

I think that leaves the question, which is more important,
a simplification of the cases or leaving in the relay only
case so that it's necessary to report ORIGINATOR (not
ROUTABLE) attached to an address which is, by type, routable?
(If a node can always find a non-routable originator address
that would also help. But that might be tricky for IPv4 at
least.)

---

From: Henning Rogge <[email-masked]>
Date: Thu, 22 Apr 2010 17:53:15 +0200

Am Donnerstag 22 April 2010 17:45:52 schrieb Dearlove, Christopher (UK):
> > I think there might be a problem for pure relays, routers without a
> > globaly routable IP (just a relay with linklocal IPs or something
> > similar).

> > How can the neighbors put this relay into their TCs without someone
> > building a route towards it ?
> 
The two-TLV sollution is not that bad if we sort the addresses by category. 
Unfortunately we cannot do this with multiple TLVs so having a three state 
(four state if we count 0 = not routable, not originator) would be better.

> maxim) or leave unspecified (which we shouldm, and do, not do).
I think OLSRd should forbid having the same IP in multiple times in a TC. Just 
drop the packet if this happens, so it cannot crash parsers.
 
> ROUTABLE) attached to an address which is, by type, routable?
I would like to keep the relay option. OLSRv2 can be used for other types of 
addresses than IP, so we cannot rely on detecting the 'type' of address.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 23 Apr 2010 09:56:54 +0100

> The two-TLV sollution is not that bad if we sort the addresses by
category.

It still costs, and chews up TLV space, and for things that
basically are the same.

> (four state if we count 0 = not routable, not originator) would be
better.

Three state is what we currently have.

> drop the packet if this happens, so it cannot crash parsers.

I think that's a mistake, and will be noncompliant. It's
actually easier without it. With it you have to check for
duplicates, which is not a linear operation. Without it
you can just go through addresses, if the address has the
appropriate flags, process it this way, that way, or both
ways. Note that processing the same information twice is
painless (you just replace a Tuple by another Tuple that's
the same) should you receive that. We do not want to force
people to make checks that are potentially expensive and
aren't actually needed.

I also don't see how that crashes parsers. It might crash
a badly written set of processing after the parser. But it's
not difficult to write code that doesn't crash.

I think I'm backtracking on my agreement. I think you have
to either assume a relay-only node can finds a recognisably
non-routable originator address (which as you note might be
tricky) or stick with three states. Once you have three
states, processing isn't actually difficult. Nor is sending
TC messages if you pick a simple heuristic and follow it,
it just gets trickier if you try to produce the "best"
representation (which does require sorting addresses in
many cases, and may involve one or two TLVs).