Re: [Manet-dt] Generalised OLSR packet/message format comments - multivaluedness

[Ian Chakeres <[e-mail]>]

Comments inline.

On 1/30/06, Dearlove, Christopher (UK) <[e-mail]> wrote:
>
<snip>
>
> (g) TLVs are more difficult. We have used two bits of the TLV
>     type, for multivalue and for user. [Note: we want the
>     packet/message parsing code to be type independent, which
>     it currently is. Having the multivaluedness type dependent
>     in an unknown way breaks this, which is not acceptable.
>     In addition note that we may have single and multivalue
>     versions of the same type, which we have imposed rules on
>     to make certain simplified parsing options - which some
>     members of the OLSR community want - possible. This also
>     applies to various other possibilities.] There are many
>     good things we could do with more bits (for example 0, 8
>     or 16 bit value lengths - the first of these for where the
>     type is the information - sub-octet values in multivalue
>     fields, control options for unknown TLVs - ignore, remove,
>     discard message). Putting aside the complexity and value
>     tradeoffs of such options, there's a major problem of not
>     having the bits. We just might manage one more bit, but
>     after that, based on the number of options just for OLSR
>     that have been proposed, it starts getting tricky. I do
>     have one idea what to do here, with (as ever) pros and cons,
>     but I want to think about it a bit more before deciding if
>     it's a candidate.

I'd like to discuss multivaluedness. Why would having this behavior be
type dependent break something? In OLSRv2 you could still define your
types to actually match this criteria for simplicity (for example
using 0001 and 0101 for the same type one being multivalued).  I don't
know whether this needs to go into the generalized format.

What do you think?

Ian

_______________________________________________
Manet-dt mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/manet-dt