Re: [manet] packetbb update idea

Hi Chris,

It is just a FORMAT, nothing else, it is very simple but can
create/make/solve problems.

It is very important to update any standard that is DEPENDENT, usually the
strategy is we design protocols for solving-problem then the messages, but
our group done a standard to focus our protocols but we never
said/discussed we don't update only if there is a BIG reason for that. IMO
it is not correct strategy to not update RFC5444 which is general. I agree
it was a problem done by this group to make a standard for packet/message,
so now you are not finding easy ways to update (we designed not flexible
standard-format maybe!!!). If flexible format it should be able to be
updated easily.

You said:

> I really, definitely see this as introducing serious problems for no
demonstrated gain. I'll be opposing this as strongly as I can.

I disagree with not updating strategy, and we need to not make roles of not
updating only if ''getting major gains''.

You said:

>No, I'm not going to describe my ideas for improvement because they miss
the point that the gains are minor, everything can be done in another way,
and the costs are serious - every implementation out there has to either
change or no longer guarantee backward compatibility.

The point was to discuss solutions and updating is one solution by Justin,
and/or discussing other solutions with not updating is your approach, so
you can describe your ideas.

Few in MANET WG  had the idea of better gain in the past was that we
publish reactive and proactive standards before doing their used general
packet format (packetbb idea), but while we done the packet first we can
update. However, now we have 5444 and only one routing standard, so we may
need to discuss ideas/solutions and then update for design-flexibility any
incorrect idea or format or strategy.

AB

On Fri, Jul 7, 2017 at 1:05 PM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

> Having protocols (other than SMF) is a possible area for future work. But
> has absolutely nothing to do with any updates to RFC 5444.
>
>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *T*:  +44 3300 467500 <+44%20330%20046%207500>  |  *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 *Abdussalam
> Baryun
> *Sent:* 07 July 2017 11:56
> *To:* Justin Dean
> *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
> <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.
>
>
>
> Hi Justin,
>
>
>
> I thank you for this issue, yes we need to look into more issues of
> manet-routing specially multicast. In MANET we done only simple multicast
> using packetbb, but does packetbb solve most problems of Multicast Routing
> in MANETs? IMO it needs update for that.
>
>
>
> AB
>
>
>
>
>
>
>
> On Mon, Jul 3, 2017 at 7:29 PM, Justin Dean <bebemaster@gmail.com> wrote:
>
> So while trying to encode some information using packetbb for the elastic
> multicast stuff we have been working on I've run into a short coming.
> RFC5444 allows one to efficiently encode information about addresses and
> even pairs of addresses (as long as one of those addresses is the Oaddr)
> with the TLV structure and the address block.  It does not allow for easy
> encoding about pairs of addresses of which neither is the Oaddr.  After
> some thinking on it I think most of what I'd like to be able to do could be
> solved by using the RESERVED tlv flag bit number 6 to indicate inclusion of
> a single index field <index-opt> which would specify a single address in
> the address block.
>
> So the tlv definition would change from
>
> <tlv> := <tlv-type>
>
>                 <tlv-flags>
>
>                 <tlv-type-ext>?
>
>                 (<index-start><index-stop>?)?
>
>                 (<length><value>?)?
>
> to
>
> <tlv> := <tlv-type>
>
>                 <tlv-flags>
>
>                 <tlv-type-ext>?
>
>                 <index-opt>?
>
>                 (<index-start><index-stop>?)?
>
>                 (<length><value>?)?
>
>
>
> This would allow one to specify information about pairs of addresses in a
> compact way.  In the case of elastic multicast source/destination flow
> pairs. Thoughts welcome.
>
>
>
> Justin
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> ********************************************************************
> 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.
> ********************************************************************
>