Subject: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation

From: Henning Rogge <[email-masked]>
Date: Tue, 1 Jul 2014 15:45:14 +0200

Hi,

I have been working for the last weeks to adapt my OLSRv2 implementation
to draft-dearlove-manet-olsrv2-multitopology.

In general the draft is straight-forward to implement, especially when
the data structures can be tailored to the draft.

The only part of the draft that feels a bit strange and complicated is
the handling of the MPR_TYPES and ATTACHED_NETWORK tlvs in the TC.

Making the MPR_TYPES tlv optional for TC messages mean that there is no
TLV left to directly determine MT-capability of the originator of the TC.

Making the MPR_TYPES depend on the configuration of the locally attached
networks "distance" also complicates things a bit.

I am not sure we should change this part of the draft, but a few
examples of TCs (with/without MPR_TYPES, with common/different distances
in attached networks) would help.

----

I am also looking for a chance to do some interop tests for the MT
codebase. The code is not that trivial so an interop test would be a
good chance to find subtle bugs.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 1 Jul 2014 16:24:57 +0000

Henning

Great to hear you've been working on this.

I had to dig out the specification to look at the TLV_TYPES issue. And I started to type that you didn't need to know (though of course it was there as optional to allow you to know). But thinking about it - though not for long enough, I'm not so sure about that. Unfortunately I don't have any more time today, but definitely let's kick around some cases to test that.

I'm having a bit of difficulty with the rest of the message. By ATTACHED_NETWORK do you mean GATEWAY? And I don't understand the following paragraph. But let's throw it all in the discussion.

Christopher

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance 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 Henning Rogge
Sent: 01 July 2014 14:45
To: [email-masked]
Cc: Christopher Dearlove
Subject: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation

Hi,

I have been working for the last weeks to adapt my OLSRv2 implementation to draft-dearlove-manet-olsrv2-multitopology.

In general the draft is straight-forward to implement, especially when the data structures can be tailored to the draft.

The only part of the draft that feels a bit strange and complicated is the handling of the MPR_TYPES and ATTACHED_NETWORK tlvs in the TC.

Making the MPR_TYPES tlv optional for TC messages mean that there is no TLV left to directly determine MT-capability of the originator of the TC.

Making the MPR_TYPES depend on the configuration of the locally attached networks "distance" also complicates things a bit.

I am not sure we should change this part of the draft, but a few examples of TCs (with/without MPR_TYPES, with common/different distances in attached networks) would help.

----

I am also looking for a chance to do some interop tests for the MT codebase. The code is not that trivial so an interop test would be a good chance to find subtle bugs.

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

********************************************************************
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: Tue, 1 Jul 2014 18:49:48 +0200

> Great to hear you've been working on this.

Thank you.

> I had to dig out the specification to look at the TLV_TYPES issue. And I started to type that you didn't need to know (though of course it was there as optional to allow you to know). But thinking…

You only need to know the TLV_TYPES value if you only have link-metric
TLVs and nothing with an array (e.g. GATEWAY tlv for TCs). But the
code-path to parse this looks a little bit twisted.

> I'm having a bit of difficulty with the rest of the message. By ATTACHED_NETWORK do you mean GATEWAY? And I don't understand the following paragraph. But let's throw it all in the discussion.

Yes, I named the API in my code after the data-structures in the
OLSRv2 RFC, thats why I accidentally said "attached network" and not
"gateway"... GATEWAY is the correct TLV name for Attached Network Set
data.

The rules when you need/don't need a TLV_TYPES tlv in a TC message
read like an exception with an exception.

a) normally you don't need it
b) unless you have Gateway TLVs
c) unless all Gatways TLVs have the same "distance" for each metric
(or have single-byte distance values)

This feels a bit strange... so maybe we could add a couple of examples.

1) Multitopology TC without any GATEWAY tlv (this means no TLV_TYPES tlv)
2) Multitopology TC with two GATEWAY tlvs and random "distances" (this
means it needs a TLV_TYPES tlv)
3) Multitopology TC with two GATEWAY tlvs, each of them having a
multi-byte "distance" values (but all the same, needs a TLV_TYPES tlv)
4) Multitopology TC with two GATEWAY tlvs, each of them having only a
single-byte "distance" value (no TLVTYPES tlv)

maybe even one with a mixture of 3) and 4) (to show you can mix both
GATEWAY tlv variants.

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 2 Jul 2014 00:36:38 +0100

Far too late at night for me to consider in detail, but I see what you are saying. I need to check details (and some more basic ones).

Of course one of the things that WGLC is for is to consider if changes are needed. Possibly examples, possibly less permissive rules.

As ever we are pulled in the three directions of simplicity, efficiency and flexibility. Actually here the last of these isn't the issue. (It drives the whole design though.) Which is preferable, rules that try to make something mandatory only when needed, or rules that are simpler (maybe even right down to simply making the TLV mandatory)? Let's have the discussion and see if we want to keep it as it is, or change it. Something that would influence that is is there a use case for wanting to be able to tell from a TC message that the originator supports MT-OLSRv2? (Right this second I actually am surprised we don't always need to know, but it's past midnight and I know I'm not firing on all cylinders.)

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 Jul 2014 12:19:32 +0000

First, I haven't discussed this with my co-author, this is just me.

I've looked through the draft again, and found a few nits I won't list here. But I also looked at Henning's point.

In short, I think we should make MPR_TYPES compulsory in MT-OLSRv2 TC messages.

This makes things simpler, Henning's point. Also 7.1.1 describes this TLV for HELLO messages (second paragraph) but doesn't have an equivalent for TC messages. That needs adding regardless, this would make what's added simpler. Of course there are other places to address, such as the first bullet in 9.1.

But that's not my main motivation. Rather I want to use this to protect against something that is not sensible, but not actually banned, and I could invent a different extension to use (though the only one I have so far is forced).

This is that in non-MT-OLSRv2, a router sends TC messages with metrics of type LINK_METRIC_TYPE. But it can put other metrics in. They are ignored, but legal. (Possible extension to use them, advertising in advance of a change of metric type for some reason I can't think of.)

So what if a non-MT-OLSRv2 router does that (pointless but legal) thing? An MT-OLSRv2 router will try using those metrics (of they are of  a type it uses). But the router being non-MT-OLSRv2 won't route using them.

If we require MT-OLSRv2 routers to put an MPR_TYPES TLV into TC messages, we can modify 9.2 to use only those metric types advertised in an MPR_TYPES TLV, or LINK_METRIC_TYPE if none, avoiding this (theoretical, but let's do it right) problem.

If this makes sense (and obviously I'd like Thomas and Henning's comments, plus of course anyone else) I'd consider this as part of the collected WGLC comments, after which we'll produce a new draft as usual. Unless both people want it earlier and I find time to do it earlier (which I may well not).

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 01 July 2014 17:50
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; [email-masked]; Christopher Dearlove
Subject: Re: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation

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

Thank you.

> I had to dig out the specification to look at the TLV_TYPES issue. And I started to type that you didn't need to know (though of course it was there as optional to allow you to know). But thinking…

You only need to know the TLV_TYPES value if you only have link-metric TLVs and nothing with an array (e.g. GATEWAY tlv for TCs). But the code-path to parse this looks a little bit twisted.

Yes, I named the API in my code after the data-structures in the
OLSRv2 RFC, thats why I accidentally said "attached network" and not "gateway"... GATEWAY is the correct TLV name for Attached Network Set data.

The rules when you need/don't need a TLV_TYPES tlv in a TC message read like an exception with an exception.

a) normally you don't need it
b) unless you have Gateway TLVs
c) unless all Gatways TLVs have the same "distance" for each metric (or have single-byte distance values)

1) Multitopology TC without any GATEWAY tlv (this means no TLV_TYPES tlv)
2) Multitopology TC with two GATEWAY tlvs and random "distances" (this means it needs a TLV_TYPES tlv)
3) Multitopology TC with two GATEWAY tlvs, each of them having a multi-byte "distance" values (but all the same, needs a TLV_TYPES tlv)
4) Multitopology TC with two GATEWAY tlvs, each of them having only a single-byte "distance" value (no TLVTYPES tlv)

maybe even one with a mixture of 3) and 4) (to show you can mix both GATEWAY tlv variants.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 3 Jul 2014 08:54:56 +0200

Hi,

I think this change makes sense... it adds some overhead, but it makes
it easier to create new extensions which require metric values.

I assume that a MT capable node which is configured to use only a
single metric could still drop the MPR_TYPES tlv?

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 3 Jul 2014 08:32:28 +0100

It would have to be supporting just the LINK_METRIC_TYPE type. Supporting just one type, but another one, it would still need to include it. Good point.

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

> On 3 Jul 2014, at 07:54, Henning Rogge <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 3 Jul 2014 08:30:27 +0000

In that case, it can (I think) also be allowed to not include it in a HELLO message. After all, to the outside it just looks like non-MT-OLSRv2.

-----Original Message-----
From: Christopher Dearlove [mailto:[email-masked]] 
Sent: 03 July 2014 08:32
To: Henning Rogge
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] draft-dearlove-manet-olsrv2-multitopology review and implementation

>> This is that in non-MT-OLSRv2, a router sends TC messages with 
>> metrics of type LINK_METRIC_TYPE. But it can put other metrics in. 
>> They are ignored, but legal. (Possible extension to use them, 
>> advertising in advance of a change of metric type for some reason I 
>> can't think of.)
>> 
>> Communications, Networks and Image Analysis Capability BAE Systems 
>> Advanced Technology Centre West Hanningfield Road, Great Baddow, 
>> Chelmsford, CM2 8HN, UK
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace 
>> Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & 
>> Wales No: 1996687
>> 
>>