Re: [manet] packetbb update idea

+1 to Chris' points

Sent from my iPad

> On 5 Jul 2017, at 22:59, Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
> 
> The demerits of a change are major, so there has to be a very solid reason. It's easy to think of things that might have some value, I could give you half a dozen.
> 
> And the use case is easily solved with a bit field. Yes, reordering the addresses changes the bit patterns. So what? Nothing disallows that. We already use the index numbers.
> 
> I really, definitely see this as introducing serious problems for no demonstrated gain. I'll be opposing this as strongly as I can.
> 
> -- 
> Christopher Dearlove
> christopher.dearlove@gmail.com
> 
>> On 5 Jul 2017, at 21:09, Justin Dean <bebemaster@gmail.com> wrote:
>> 
>> 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) <chris.dearlove@baesystems.com> 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:  +44 3300 467500  |  E: chris.dearlove@baesystems.com
>>> 
>>> 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:manet-bounces@ietf.org] On Behalf Of Justin Dean
>>> Sent: 03 July 2017 20:59
>>> To: Henning Rogge
>>> Cc: manet@ietf.org
>>> 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.
>>> If you feel the email is suspicious, please follow this process.
>>> 
>>> *** WARNING ***
>>> EXTERNAL EMAIL -- This message originates from outside our organization.
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> On Mon, Jul 3, 2017 at 2:56 PM, Henning Rogge <hrogge@gmail.com> wrote:
>>> 
>>> On Mon, Jul 3, 2017 at 8:36 PM, Justin Dean <bebemaster@gmail.com> 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.
>>> ********************************************************************
>>> 
>> 
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet