Re: [manet] packetbb update idea

[Justin Dean <[e-mail]>]

I don't see how having a bit field would work as the order of the addresses
in the address block are not guaranteed to be in any specific order.  My
example was meant to be a simple illustration what we are working on
contains possibly many more addresses and many more associations.

In terms of the headache of updating the specification I agree it's not
trivial but I don't think protocols which have been developed and specify
version 0 would have to be updated.  The only reason they would need to be
updated is if they were using an extension which specified use of version
1.  New protocols could specify version 0 or version 1 depending on
protocol requirements.  I also don't think we should update it right away
though as their may be more changes that might be helpful (like the chained
address blocks for example), but I'm against shooting it down outright
because it would cause difficulties due to versioning.  The version number
is there for a reason, it just shouldn't be abused.

If at all possible I'd like to focus this specific discussion on the merits
(or lack of) of the proposed change.  If people would find it useful then
we can have a discussion on if it's worth a version update, or add it to a
list of nice things to have in a later/future version update.

Justin

On Tue, Jul 4, 2017 at 4:51 AM, Dearlove, Christopher (UK) <
[e-mail]> wrote:

> 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] <+44%20330%20046%207500>  |  *E: *
> [e-mail]
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
> Baddow, Chelmsford, Essex CM2 8HN.
> 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]> wrote:
>
> On Mon, Jul 3, 2017 at 8:36 PM, Justin Dean <[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.
> ********************************************************************
>