Re: [manet] packetbb update idea

["Dearlove, Christopher (UK)" <[e-mail]>]

As you indicate, that takes multiple TLVs. You can do it with a single TLV (and even indicate directionality, should you want to) by using a multivalue TLV with a bit vector single value. That’s a definite saving in that case.

Really, theirs is a major overhead in introducing a change, it’s a lot more than simply updating 5444. For a start the existing protocols reference version 0. But if the update is to be of any application, do they need updating? And then we have compatibility issues over existing implementations - and we just had a report of an interoperability case. And more. It really has to be a compelling case, and this wouldn’t be that even if the alternative were slightly more inefficient. But it’s not - it’s more efficient.

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

T:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

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

From: manet [mailto:[e-mail]] On Behalf Of Justin Dean
Sent: 03 July 2017 20:59
To: Henning Rogge
Cc: [e-mail]
Subject: Re: [manet] packetbb update idea


*** 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://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Dealing%20With%20Suspicious%20Emails.pdf>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



On Mon, Jul 3, 2017 at 2:56 PM, Henning Rogge <[e-mail]<mailto:[e-mail]>> wrote:
On Mon, Jul 3, 2017 at 8:36 PM, Justin Dean <[e-mail]<mailto:[e-mail]>> wrote:
>> You mean for things like source-specific routing (having a source- and
>> destination prefix for an attached network)?
>>
>> I remember I did a rough sketch for this (I have implemented in my
>> Olsrd2-Implementation) and I was forced to put one of the addresses
>> uncompressed into a data TLV.
>>
> Yes it could work for that.  I did the same thing when I started to sketch
> out a layout that worked with RFC5444.  Having the extra index instead of
> including the full address saves a bunch of space when transmitting a lot of
> pairwise information. 1 byte instead of 16 when working with ipv6.

why not add a single TLV with 1 byte (multivalue) for all addresses?
This would give you the second index with just a constant overhead (2
bytes? 3?) per address block.

Not sure I'm understanding what your suggesting or I'm not clearly expressing myself.  An example.  I want to encode a graph structure in RFC5444.
I have 4 addresses in the following configuration.

A-----B
|    /|
|   / |
|  /  |
| /   |
|/    |
C-----D

With current RFC5444 assuming I'm 1 I could do something like.
address block <B,C,D>
originator address A
TLV (link to oAddr) index B,C.  This would indicate A-B, A-C
TLV (link to address in the value field)  index addresses B,C with TLV value field of address D.  This would indicate B-D and C-D.
TLV (link to address in the value field) index address B with TLV value field of address C.  this would indicate B-C
This wouldn't be so bad except that the value field has to include the full address D and C instead of just indexing them.  It also makes the value field encoding messy if you start adding metric values to the links.

With the optional address using included (using bit 6) it would allow for TLV association between two addresses without actually fully including one of those addresses in the value field.

This is just an example but there we have both encountered encoding problems in which we wanted to associate addresses in the address block somehow, often with a metric or value associated with it.  This is a way that would allow us to do so cleanly.  Their may be other ways too.
********************************************************************
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.
********************************************************************