Subject: [manet] TC content in olsrv2-11

From: Henning Rogge <[email-masked]>
Date: Wed, 28 Jul 2010 16:57:09 +0200

Hi,

I have some problems with the current description of the TC generation
in the current OLSRv2 draft (11).

Section 15.1 states that the address block(s) of a TC contain the
following content:
1.) originator IPs of neighbors
2.) interface IPs of neighbors
3.) local attached networks

I see two potential problems with the current version:
a) we do not put the interface IPs of the local node into the TC. Is
this something missing or a design choice ? It means we might get a TC
from a node, but do not know all routable addresses of it.
b) we put all originators and interface IPs of the neighbor into the
TC, without any method to keep the addresses of different neighbors
apart. This means a lot more work for the dijkstra algorithm because
we multiply the number of nodes in the graph by the number of
"interfaces+1".

There is an easy way to solve problem a) by putting the interface IPs
of the local node into the TC, marked by a third tlv (nbr_addr_type,
gateway are already existing for marking TC addresses).
I'm not sure how we can solve problem b) in a clean way.

Another inconsistency of the current TC content is the design of the
NBR_ADDR_TYPE tlv (section 15.2.2).
If we demand (for HELLO messages) that routable/non-routable must be
decidable by looking at the value of the address, we don't need the
ROUTABLE_ORIG combination. Loosing this option would mean we cannot
handle ID-numbers as originator addresses that are not IPs at all.
If we want to keep the option about having non-routable (non-ip ?)
originator-IPs, we need a way to mark them with a non-routable
attribute in the HELLO messages. If we do this we should add this
option for interface IPs in HELLOs too, to stay consistent.

Henning Rogge

-- 
"Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand
ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt
Marti)

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 28 Jul 2010 16:17:02 +0100

> this something missing or a design choice ?

Design choice.

> It means we might get a TC

We will, once we get a TC from a neighbour of that router. The whole
point was to reduce the size of TC messages, as various people have
requested.

>we multiply the number of nodes in the graph by the number of

Not so, because we have a single originator address so the we use
Dijkstra on originator addresses, then "decorate" with additional
addresses. As described in the draft.

> I'm not sure how we can solve problem b) in a clean way.

Already solved in both cases.

> NBR_ADDR_TYPE tlv (section 15.2.2).

This is also a design choice, for extensibility. We need all addresses
in the TC to be flagged by a TLV, otherwise you cannot extend a TC
message tro add addresses for anotherpurpose. The flagging as routable
isn't necessary as you note, we could just flag
originator/non-originator.
But once we have such a TLV, flagging as routable is free, and
simplifies
processing.

> decidable by looking at the value of the address

That's because we don't need such a TLV, so there would be a space
overhead in adding such a TLV.

> If we do this we should add this

Consistency that costs overhead just for consistency is not a good
tradeoff.

********************************************************************
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: Wed, 28 Jul 2010 18:20:12 +0200

> point was to reduce the size of TC messages, as various people have
Okay, this is a really bad design choice. We just broke the ability to
even detect which address is owned by which node.

> addresses. As described in the draft.
This neighbor interface addresses will be (with different costs)
connected to different originators, so it still have to be included
into the dijkstra algorithm. You cannot assume that you have found the
best route to an neighbor interface address only because you found the
best route to the originator of the neighbor, at least you will not be
able to do as soon as we fold in routing metrics.

> Already solved in both cases.
I don't think so.

> simplifies processing.
That's why I suggested to ADD a value to allow us removing links from
the topology. It does not cost us overhead but can be an important
feature for fast roaming of non-manet nodes between a MANET with
access points on the nodes... or with pushing fast status changes when
the internet access (and with it, the HNA 0/0) of a gateway router
goes up/down.

We are missing something here we missed before on OLSRv1, so I don't
think we have a consensus on this point.

We won't have overhead with the configurations we support at the
moment, because we don't need to add the "routable/non-routable" int
this case into the Hello, but we WILL support the other use case. We
will have a little bit overhead in the Hellos, but save a lot of bytes
by sending much smaller TCs for the updates.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 28 Jul 2010 17:24:49 +0100

Why do we care?

This is a routing protocol. The objective is to get a packet
to the next hop along its route to its destination. Why do I
care which packets go to similar destinations and which don't 
as long as they all get where they should go?

If you have another reason, beyond routing, to care, then
create a protocol extension. But those who just want routing
shouldn't have to pay that cost.

-- 
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: Henning Rogge [mailto:[email-masked]] 
Sent: 28 July 2010 17:20
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] TC content in olsrv2-11

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

I don't think so.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 28 Jul 2010 17:46:06 +0100

Henning
> able to do as soon as we fold in routing metrics.

It's true it's not quite as straightforward with metrics. But you still
don't have to just treat them as nodes in the fill algorithm, but there
is still a cheaper process than just increasing the number of nodes in
the Dijkstra algorithm.

> the topology.

I have great reservations about "negative delta" messages, which is what
you are in effect proposing.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 28 Jul 2010 17:55:22 +0100

Henning
> gateway are already existing for marking TC addresses).

Incidentally, if I accepted that (a) is a problem (which I don't) then
this would not be a solution, easy or otherwise, as not all nodes send
TC messages. That was the problem with MID messages in OLSRv1 (which
this is reinventing) - and node with more than one address had to send
one, thus removing much of one of the two MPR-based optimizations of
OLSR.

---

From: "Justin Dean" <[email-masked]>
Date: Wed, 28 Jul 2010 13:24:24 -0400

I think Henning has a point although not quite as strong as he might think.
The key point from section 15.1....

N_neighbor_addr_list of a Neighbor Tuple with N_advertised = true MUST be
represented....

Where N_neighbor_addr_list from NHDP is an unordered list of the network
addresses of a 1-hop neighbor(the Neighbor Tuple,) and Neighbor Tuple is
part of the Neighbor Information Base of which there is one per router.
Notice that the Information Base is not per interface but per router.

What this means is that when a TC is sent links to all MPR selectors
(including ALL of their addresses) will be included.  It doesn't matter what
specific set of links or link is being used just that there is a link
between the originator address and that set of addresses.  You only need to
include the originator address and not the whole list of local addresses
because, any time you would know about the any of a nodes addresses you know
about all of them.

A silly analogy because I like them.
I know how to get to (the green people) Bobby and Suzy.
Bobby (who is green) can get to (the blue people) Frank and Sally, and (the
red people) Tom and Joe. 
Frank (who is blue) can get to (the green people) Bobby and Suzy, and (the
orange people), Jake.
Names = specific addresses; Color of People = Neighbor Tuples (group of
addresses)

You don't really need to know that people are grouped in colors if it's
guaranteed that everyone MUST advertise all the people in a given color if
they are to advertise ANY of them.  And in fact OLSRv2 is suggesting to not
use this grouping at all as its extra overhead.

I say Henning has a point because how to include/calculate the metric to
advertise in a TC based on multiple links is not trivial. A router with a
high bandwidth high delay sat link and a low bandwidth low delay ground
radio should advertize what?  The best of either?  The best overall link?  A
combination?  This is a problem.

I also like the idea of having a LOST link message which explicitly removes
a link.  It doesn't have to be used but might be useful in certain
situations.

Justin

      true MUST be represented by address objects in one or more Address
      Blocks
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dearlove, Christopher (UK)
> Sent: Wednesday, July 28, 2010 12:25 PM
> To: Henning Rogge
> Cc: [email-masked]
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Henning Rogge <[email-masked]>
Date: Thu, 29 Jul 2010 08:41:49 +0200

I don't think you got my point with the NBR_ADDR_TYPE tlv. If we keep
the decission that we can decide routable/non-routable by looking at
the address, we only need two tlv types for it: "originator" and
"interface". The two different encodings for routable/non-routable
originator are not useful because we can do this based on the value of
the address.

We will still mark all neighbor addresses in the TC with the
NBR_ADDR_TYPE tlv, we can just get rid of an unnecessary type.

We might add a third type for "non-reachable" later if we decide to
introduce the negative delta, but at the moment we only need two tlv
types.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 29 Jul 2010 09:27:51 +0100

> combination?  This is a problem.

With a single metric, you advertise the best (lowest metric). That's in
the
metrics draft. Once you are considering more than one aspect of a link
you
are into multi-topology and multi-metric territory. That's a natural
extension of what's in the metrics draft, but we have to draw a line
somewhere.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 29 Jul 2010 09:35:04 +0100

> If we keep
> "interface".

Not quite. Originator and non-originator. The originator address might
also be an interface address.

> NBR_ADDR_TYPE tlv, we can just get rid of an unnecessary type.

OK. I'm not absolutely against that. To some extent it's a tradeoff
of what future extensions, or features now, you want to allow for.