Subject: [manet] AODVv2 - first comment (5444 multiplexer)

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 4 Mar 2016 16:19:02 +0000

I've read some of draft -13. I will provide comments (which won't be comprehensive) in bite sized chunks rather than attempting anything consolidated. And most can wait until next week at the earliest.

But one to kick off.

The architecture mandated by 5498 is that AODVv2 creates messages, it passes them to the 5444 multiplexer. In due course it receives messages from there. There are some other details, but that's the most important.

The 5444 multiplexer is what handles UDP ports, multicast addresses and so on. It doesn't handle flooding, because its packets (which may contain multiple messages, from AODVv2 and elsewhere) only go one hop.

There are other requests that can be made to the multiplexer, most obviously which interface(s) this message is for, but also things like "please try to keep these messages together". If there are any additional requests that should be supported, and are not incompatible with the architecture, then the 5444 usage draft is a good opportunity to get those in.

But, looking at the AODVv2 draft, "multiplex" (as a whole or part word) only appears twice, both in the paragraph:

   [RFC5444] provides a multiplexed transport for multiple protocols.
   An [RFC5444] multiplexer MAY choose to optimize the content of
   certain message elements to reduce control message overhead.

I think that's not how I see it, that that's the role of the (subtlely different) 5444 message creation process from addresses and attributes. I think the multiplexer itself, given a whole message from a protocol shouldn't be modifying it. Note that I've expressed that as an opinion, though a quite strong one. A protocol might apply some sort of specialised signature, and we can't let the multiplexer destroy that. (The multiplexer might add a 7182 ICV and/or timestamp, but it will then remove them before the protocol gets the packet again.)

This is probably something that could/should be in the 5444 usage draft. If it gets WGLCed as requested, I'll submit it to myself and the rest of the author team.

So there is nothing describing how AODVv2 interacts with the multiplexer. That shouldn't matter (though it's always better to have it) if you assume 5498 applies, as it does. But unfortunately the draft still has material that contradicts that model, which needs to go. In particular (but not only) the first two paragraphs of section 6.5. This is an essential change.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

********************************************************************
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: Lotte Steenbrink <[email-masked]>
Date: Tue, 8 Mar 2016 12:09:46 +0100

Hello Christopher,

Am 04.03.2016 um 17:19 schrieb Dearlove, Christopher (UK) <[email-masked]>:

> I’ve read some of draft -13. I will provide comments (which won’t be comprehensive) in bite sized chunks rather than attempting anything consolidated. And most can wait until next week at the earliest.
>  
> But one to kick off.
>  
> The architecture mandated by 5498 is that AODVv2 creates messages, it passes them to the 5444 multiplexer. In due course it receives messages from there. There are some other details, but that’s the most important.
>  
> The 5444 multiplexer is what handles UDP ports, multicast addresses and so on. It doesn’t handle flooding, because its packets (which may contain multiple messages, from AODVv2 and elsewhere) only go one hop.
>  
> There are other requests that can be made to the multiplexer, most obviously which interface(s) this message is for, but also things like “please try to keep these messages together”. If there are any additional requests that should be supported, and are not incompatible with the architecture, then the 5444 usage draft is a good opportunity to get those in.
>  
> But, looking at the AODVv2 draft, “multiplex” (as a whole or part word) only appears twice, both in the paragraph:
>  
> I think that’s not how I see it, that that’s the role of the (subtlely different) 5444 message creation process from addresses and attributes. I think the multiplexer itself, given a whole message from a protocol shouldn’t be modifying it. Note that I’ve expressed that as an opinion, though a quite strong one. A protocol might apply some sort of specialised signature, and we can’t let the multiplexer destroy that. (The multiplexer might add a 7182 ICV and/or timestamp, but it will then remove them before the protocol gets the packet again.)

True. If I remember it correctly (Co-Authors, please stop me if I don't), what we were trying to say was "The message contents MAY be reshuffled during message creation, but please pay attention that some things MUST be kept in one message in order to form a coherent AODVv2 message." This is especially important for RERR messages, which could easily get chopped up into multiple messages if the underlying MTU is small.

If we change that paragraph to

   [RFC5444] provides a multiplexed transport for multiple protocols.
   An [RFC5444] implementation MAY choose to optimize the content of
   certain elements during message creation to reduce control message overhead.
   
and the language of, say,  7.1.3. RREQ Regeneration from

   This AODVv2 message is used to create a corresponding [RFC5444]
   message (see Section 8) which is multicast, by default, to LL-MANET-
   Routers on all interfaces configured for AODVv2 operation.  However,
   the regenerated RREQ can be unicast to the next hop address of the
   LocalRoute toward TargAddr, if known.

to something like

   This AODVv2 message is used to create a corresponding [RFC5444]
   message (see Section 8), which is handed to the RFC5444 multiplexer
   for further processing.
   By default, the multiplexer is instructed to multicast the message to LL-MANET-
   Routers on all interfaces configured for AODVv2 operation.  However,
   the regenerated RREQ can be unicast to the next hop address of the
   LocalRoute toward TargAddr, if known.

(and the same thing for 7.2.3. RREP Regeneration, 6.5. Message Transmission, etc.), would that resolve the issue?

>  
> This is probably something that could/should be in the 5444 usage draft. If it gets WGLCed as requested, I’ll submit it to myself and the rest of the author team.
>  
> So there is nothing describing how AODVv2 interacts with the multiplexer. That shouldn’t matter (though it’s always better to have it) if you assume 5498 applies, as it does.

I've always assumed the 5444 message creation process to be part of the "RFC5444 component" rather than part of the "AODVv2 component", which is why I thought the AODVv2<->RFC5444 interaction that should be described clearly was the part where AODVv2 tells the 5444 message creation process what a message looks like (and where it should be sent). I've assumed that this is the part where AODVv2 hands over all control to 5444, so obviously it wouldn't multicast a message *itself*, it would instruct the multiplexer to do so. I wasn't aware that this must be stated explicitly.

I'm not sure if this is a subtlety or a misconception that should be clarified in the 5444-usage draft...

With kind regards,
Lotte Steenbrink

> But unfortunately the draft still has material that contradicts that model, which needs to go. In particular (but not only) the first two paragraphs of section 6.5. This is an essential change.
>  
> --
> 
> Christopher Dearlove
> T:  +44 (0)1245 242194  |  E: [email-masked]
> 
> www.baesystems.com/ai
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 8 Mar 2016 13:21:35 +0000

I'm reading this on a phone, so I'm going to wait until I can read it better for longer comment.

But there are, and I think this is a potential source for confusion, two things in 5444. One is about formats, one is about multiplexing.

Formatting (and parsing) isn't defined as a process, but as formats. Many people (everyone?) who uses 5444 will create a general 5444 formatter/parser. That's up to the implementer to decide what to make it do, whether to optimise in that formatter, outside the formatter, or not at all. (Personally I have some inside, some outside.)

The other component is the 5444 multiplexer (and denultiplexer). That takes 5444 formatted messages (and  possibly some other things) and forms 5444 packets. It is important that the 5444 multiplexer returns messages as delivered to it (hop count and limit apart of course). Otherwise security features in the protocol may fail. Note that doesn't prevent the multiplexer modifying the message before putting it on the wire, that just needs to be reversible. And obvious example is if you implement 7182 ICVs and TIMESTAMPs in the multiplexer, if it adds them, it also needs to remove them before handing the message to the protocol. (You may instead put this in the protocol.)

Yes, I think the usage document could gain from adding this. Note, that's personal only, my co-authors haven't agreed to that yet. But largely because I haven't asked them yet (with one partial exception).

The points I think are:
- Two things in 5444. Format and multiplex.
- Generic formatter/parser not required, but recommended. Optimisation optional.
- Multiplexer must deliver messages as sent (hop exception). But may modify reversibly. 7182 example (could implement message level in multiplexer, must implement packet level there).

-- 
Christopher Dearlove
[email-masked]

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)
> On 8 Mar 2016, at 11:09, Lotte Steenbrink <[email-masked]> wrote:
> 
> Hello Christopher,
>

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 8 Mar 2016 14:33:43 +0100

My position on this matter is by an large "what Chris said", fwiw.

Thomas

> On 08 Mar 2016, at 14:21, Christopher Dearlove <[email-masked]> wrote:
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 10 Mar 2016 16:56:26 +0000

Actually, I was wrong about there being a hop exception. As hop count/limit updates are the protocol’s job, even they are to be unchanged by the multiplexer.

I’ve also identified - and this is the place to fix it - that the errata to 5444 doesn’t go far enough. Someone (Henning perhaps) spotted that the packet sequence number should be per interface, as it always had been in OLSRv1, and we got that put in as an erratum to 5444. Actually it should be per (interface, destination). Not an issue when, like NHDP/OLSRv2, everything uses the same broadcast/multicast address. But if packets might be unicast (always intended as an option, and AODVv2 may do it) then it needs to also be per destination to be useful.  Easily added.

From: Thomas Clausen [mailto:[email-masked]]
Sent: 08 March 2016 13:34
To: Christopher Dearlove
Cc: Lotte Steenbrink; Dearlove, Christopher (UK); [email-masked]; [email-masked]
Subject: Re: [manet] AODVv2 - first comment (5444 multiplexer)

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
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>.
My position on this matter is by an large "what Chris said", fwiw.
Thomas

On 08 Mar 2016, at 14:21, Christopher Dearlove <[email-masked]<mailto:[email-masked]>> wrote:
I'm reading this on a phone, so I'm going to wait until I can read it better for longer comment.

The points I think are:

--
Christopher Dearlove
[email-masked]<mailto:[email-masked]>

--
Christopher Dearlove
[email-masked]<mailto:[email-masked]> (iPhone)
[email-masked]<mailto:[email-masked]> (home)
On 8 Mar 2016, at 11:09, Lotte Steenbrink <[email-masked]<mailto:[email-masked]>> wrote:
Hello Christopher,

Am 04.03.2016 um 17:19 schrieb Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>>:

But one to kick off.

   An [RFC5444<https://tools.ietf.org/html/rfc5444>] implementation MAY choose to optimize the content of

and the language of, say,  7.1.3<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-7.1.3>. RREQ Regeneration from

   This AODVv2 message is used to create a corresponding [RFC5444<https://tools.ietf.org/html/rfc5444>]

   message (see Section 8<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-8>) which is multicast, by default, to LL-MANET-

to something like

   This AODVv2 message is used to create a corresponding [RFC5444<https://tools.ietf.org/html/rfc5444>]

   message (see Section 8<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-8>), which is handed to the RFC5444 multiplexer

   for further processing.

(and the same thing for 7.2.3<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-7.2.3>. RREP Regeneration, 6.5<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-6.5>. Message Transmission, etc.), would that resolve the issue?

With kind regards,
Lotte Steenbrink

[email-masked]<mailto:[email-masked]>

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Thu, 10 Mar 2016 17:37:56 +0000

Hello Christopher,

From: manet [mailto:[email-masked]] On Behalf Of Dearlove, Christopher (UK)
Sent: donderdag 10 maart 2016 17:56
To: Thomas Clausen; Christopher Dearlove
Cc: [email-masked]; [email-masked]
Subject: Re: [manet] AODVv2 - first comment (5444 multiplexer)

I’ve also identified - and this is the place to fix it - that the errata to 5444 doesn’t go far enough. Someone (Henning perhaps) spotted that the packet sequence number should be per interface, as it always had been in OLSRv1, and we got that put in as an erratum to 5444.

Credit where credit is due: IIRC, it was Teco who found this.

Actually it should be per (interface, destination). Not an issue when, like NHDP/OLSRv2, everything uses the same broadcast/multicast address. But if packets might be unicast (always intended as an option, and AODVv2 may do it) then it needs to also be per destination to be useful.  Easily added.

Interestingly, in olsrd2 Henning seems to be using unicast RFC5444 packets for ‘neighbour probing’ (i.e., to generate some data that the ‘minstrel’ algorithm can use to decide on the optimal transmit rate for a WLAN interface, which in turn is an input to the DAT metric calculation …. if I have understood all of this correctly).

Best regards,
Ronald

From: Thomas Clausen [mailto:[email-masked]]
Sent: 08 March 2016 13:34
To: Christopher Dearlove
Cc: Lotte Steenbrink; Dearlove, Christopher (UK); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [manet] AODVv2 - first comment (5444 multiplexer)

*** WARNING ***

The points I think are:

But one to kick off.

to something like

   for further processing.

With kind regards,
Lotte Steenbrink

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 10 Mar 2016 19:14:32 +0100

On Thu, Mar 10, 2016 at 5:56 PM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> Actually, I was wrong about there being a hop exception. As hop count/limit
> updates are the protocol’s job, even they are to be unchanged by the
> multiplexer.
>
> I’ve also identified - and this is the place to fix it - that the errata to
> 5444 doesn’t go far enough. Someone (Henning perhaps) spotted that the
> packet sequence number should be per interface, as it always had been in
> OLSRv1, and we got that put in as an erratum to 5444. Actually it should be
> per (interface, destination). Not an issue when, like NHDP/OLSRv2,
> everything uses the same broadcast/multicast address. But if packets might
> be unicast (always intended as an option, and AODVv2 may do it) then it
> needs to also be per destination to be useful.  Easily added.

That is exactly how I implemented it in my (de-)multiplixer code... I
always took the "per destination" for granted and considered "same
multicast destination, same sequence number" the thing that needed to
be fixed.

my multiplexer has the concept of a "target", which is a destination
IP on an interface... and it produces a packet sequence number per
target.

Henning

---

From: Lotte Steenbrink <[email-masked]>
Date: Mon, 14 Mar 2016 17:49:29 +0100

Hello Christopher,

> Am 08.03.2016 um 12:59 schrieb Christopher Dearlove <[email-masked]>:
> 

Exactly. All I wanted to say was that my mental model looked something like this:

                    +--------------------------------+
                    | +------------+  +------------+ |
+-------------+     | |            |  |            | |
|             |     | |            |  |            | |  send
| AODVv2/     +-------> Format     +--> Multiplex  +------->
| OLSRv2/...  |     | |            |  |            | |
|             |     | |            |  |            | |
+-------------+     | +------------+  +------------+ |
                    |            RFC5444             |
                    +--------------------------------+

…Which is why I thought we’d only need to specify the transaction marked by the first arrow. In previous E-Mails about the 5444-usage draft, I’ve criticised that it’s not entirely clear how to do that correctly, and I think that this confusion is an illustration of the problem I was trying to address… Unfortunately, I haven’t gotten round to reading -02 yet, so I don’t know if this may have been resolved already.

> - Multiplexer must deliver messages as sent (hop exception). But may modify reversibly. 7182 example (could implement message level in multiplexer, must implement packet level there).

Additionally, I was wondering if you’d had a chance to look at my suggested changes by now? I’d like to fix this as soon as possible, and I want to make sure I get it right this time. :)

Best regards,
Lotte

> 
> -- 
> Christopher Dearlove
> [email-masked] <mailto:[email-masked]>
> 
> On 8 Mar 2016, at 11:09, Lotte Steenbrink <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hello Christopher,
>> 
>> Am 04.03.2016 um 17:19 schrieb Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>>:
>> 
>>    [RFC5444 <>] provides a multiplexed transport for multiple protocols.
>>    An [RFC5444 <https://tools.ietf.org/html/rfc5444>] implementation MAY choose to optimize the content of
>> and the language of, say,  7.1.3 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-7.1.3>. RREQ Regeneration from
>> 
>>    This AODVv2 message is used to create a corresponding [RFC5444 <https://tools.ietf.org/html/rfc5444>]
>>    message (see Section 8 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-8>) which is multicast, by default, to LL-MANET-
>>    This AODVv2 message is used to create a corresponding [RFC5444 <https://tools.ietf.org/html/rfc5444>]
>>    message (see Section 8 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-8>), which is handed to the RFC5444 multiplexer
>>    for further processing.
>> (and the same thing for 7.2.3 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-7.2.3>. RREP Regeneration, 6.5 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-6.5>. Message Transmission, etc.), would that resolve the issue?
>> 
>>>  
>>> T:  +44 (0)1245 242194  |  E: [email-masked] <mailto:[email-masked]>
>>> 
>>> www.baesystems.com/ai <http://www.baesystems.com/ai>
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 14 Mar 2016 17:13:40 +0000

I don’t think that’s the right picture, but I’m not going to try to draw the right one.

Rather the protocol needs to construct a message. To do that it may use a library that enables that. But the message is returned by the library to the protocols.

Why? For a start, the protocol may not have finished with the message. It might construct it in stages. In particular it might hand it off to another protocol to add to it.

For example consider that NHDP creates HELLO messages. Then OLSRv2 adds material to those HELLO messages (e.g. MPR TLVs).

Then the protocol passes the final message to the multiplexer.

Note that the multiplexer is a defined process. Formatting a message is not. While a library to do that is a natural way to work, it’s not mandatory. I know that the authors of the 5444 usage draft all have produced such libraries - but they are different in their exact models, not just their code.

And, as indicted in the usage draft, you can write a library that attempts to optimise your messages. Or rely on the code calling the library to do things optimally itself.

From: Lotte Steenbrink [mailto:[email-masked]]
Sent: 14 March 2016 16:49
To: Christopher Dearlove
Cc: [email-masked]; Dearlove, Christopher (UK)
Subject: Re: [manet] AODVv2 - first comment (5444 multiplexer)

*** WARNING ***

Am 08.03.2016 um 12:59 schrieb Christopher Dearlove <[email-masked]<mailto:[email-masked]>>:

The points I think are:

Best regards,
Lotte

But one to kick off.

to something like

   for further processing.

With kind regards,
Lotte Steenbrink

---

From: Lotte Steenbrink <[email-masked]>
Date: Mon, 14 Mar 2016 18:48:20 +0100

Hi Christopher,

> Am 14.03.2016 um 18:13 schrieb Dearlove, Christopher (UK) <[email-masked]>:
> 

I never said it was, I just wanted to illustrate where I got confused. But I guess that discussion is off-topic in this thread… :)

Best regards,
Lotte

> From: Lotte Steenbrink [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: [email-masked] <mailto:[email-masked]>; Dearlove, Christopher (UK)
> 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>.
> 
> Hello Christopher,
>  
> Am 08.03.2016 um 12:59 schrieb Christopher Dearlove <[email-masked] <mailto:[email-masked]>>:
>  
> and the language of, say,   <>7.1.3 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-7.1.3>. RREQ Regeneration from
>  
> (and the same thing for  <>7.2.3 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-7.2.3>. RREP Regeneration,  <>6.5 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-6.5>. Message Transmission, etc.), would that resolve the issue?
> 
> 
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 15 Mar 2016 08:29:40 +0100

> I don’t think that’s the right picture, but I’m not going to try to draw the

The "right" picture highly depends on the design of the Multiplexer API.

I prefer to hand of something like a "cooking receipe" (this message
TLVs, this addresses with these address TLVs) to the library and it
does the rest of the work... this allows for a simpler "work flow",
but complicates the design of the API, especially for things like
message and packet signatures.

Henning

---

From: Lotte Steenbrink <[email-masked]>
Date: Tue, 22 Mar 2016 19:09:16 +0100

Hi Christopher, hi all,

I’m very happy about the discussion going on in this thread but I’m afraid I’ve steered off topic a bit with my remarks about the 5444-usage draft– I was wondering if you’d had a chance to review my proposed changes yet and if so, do they make sense (and/or what could we do better)? I’d really like to fix this issue. :)

Best regards,
Lotte

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 23 Mar 2016 10:15:03 +0000

I really want to get to look at this - though looking at DLEP is higher priority and I haven’t got to that yet either. I’m about to be out for a week, and too many things to do before then, so I’m not sure when I can get to this.

From: Lotte Steenbrink [mailto:[email-masked]]
Sent: 22 March 2016 18:09
To: Mobile Ad Hoc Networks mailing list
Cc: Dearlove, Christopher (UK); Christopher Dearlove
Subject: Re: [manet] AODVv2 - first comment (5444 multiplexer)

*** WARNING ***

Best regards,
Lotte

The points I think are:

But one to kick off.

to something like

   for further processing.

With kind regards,
Lotte Steenbrink