Re: [Roll] 'S' field in MPL Options

[Robert Cragie <[e-mail]>]

I agree we should keep the 'S' field as it gives more flexibility for 
future versions.

I'm not sure we reached a conclusion regarding the reserved bits and 
version numbering. Here are the choices as I see them:

1) 5-bit version number:

  * Allocate all reserved bits to be a unsigned 5-bit version field:
      o V = Version. Set to 0. Must be received as 0. If received as 1
        or higher, packet is discarded

In future revisions, this allows:

  * Extension of the frame using TLV suboptions
  * Complete change to the option formatting if V is set to 1 or higher

2) n-bit (1 <= n <= 4) version number:

  * Allocate n reserved bits to be a unsigned n-bit version number:
      o V = Version. Set to 0. Must be received as 0. If received as 1
        or higher, packet is discarded
  * Change behavior for remainder of reserved bits:
      o rsv =  reserved. Set to 0. Ignored on receipt

In future revisions, this allows:

  * Extension of the frame using TLV suboptions
  * Use of remainder of reserved bits
  * Complete change to the option formatting if V is set to 1 or higher

3) No version number:

  * Change behavior for reserved bits:
      o rsv =  reserved. Set to 0. Ignored on receipt

In future revisions, this allows:

  * Extension of the frame using TLV suboptions
  * Use of reserved bits

In draft 02, it is most like (1), except the reserved bits are not 
called a version number. My preference would be for (2), with n=1.

Anyone else?

Robert


On 30/11/2012 7:49 PM, Michael Richardson wrote:
>>>>>> "Robert" == Robert Cragie <[e-mail]> writes:
>      Robert> 2. Allow future revisions to change the format
>
> I suggest that we keep the S bit.  We might introduce additional fixed
> format items using additional reserved bits to flag that they are there.
>
> If we run out of reserved bits, then that would be a reason to bump the
> version and go for a full subTLV format.  Given that bytes are scarce,
> this results in the most efficient packing for now.
>
> This is my suggestion.  If you agree, then we should add this to issue #108.
>