Re: [6lo] Future extensibility for the DAR/DAC

[Charlie Perkins <[e-mail]>]

Hello Pascal,

You have to admit that the word "legacy" in previous emails was open to 
ambiguity.

So let's define "old-legacy" to mean RFC 6775, and "new-legacy" to mean 
rfc6775-update-only.  With that terminology, I will re-write my earlier 
comment.

On 5/21/2018 11:31 AM, Pascal Thubert (pthubert) wrote:
> Hello Charlie;
>
>
> Le 21 mai 2018 à 19:36, Charlie Perkins <[e-mail] 
> <mailto:[e-mail]>> a écrit :
>
>> Hello Pascal,
>>
>> I have some follow-up comments interspersed below.
>>
>> On 5/21/2018 10:18 AM, Pascal Thubert (pthubert) wrote:
>>>
>>> Hello Charlie :
>>>
>>> This is not simple and I hope the list comes in and helps. The 
>>> reason for proposing the text below is to enable future codes to be 
>>> backward compatible with this spec.
>>>
>>
>> My suggestion also allows future codes to be backward compatible, right?
>
> I do not understand that; how would a node that implements this spec 
> process a code of 10?

In other words, how should we design variable-length ROVR fields so that 
a new-legacy node can skip past unrecognized Codes for DAR and DAC but 
still process their options?  In addition, I think we want to obey the 
constraint that old-legacy nodes can still interact with CodePfx=0 DAR 
and DAC with ROVRs of 64 bits.

If you agree with this reformulation, then I think the answer is clearly 
to define some length bits somewhere.

As currently proposed, we only need two length bits.  But maybe future 
messages will need longer verifications.  With three length bits, we get 
twice as many Codes and still very sufficient length signifiers.  Maybe 
we could have 64, 128, 192, 256, 512, 1024, 2048, rsvd.

I also think it is better to be explicit, and call the new field 
"CodeSz" or something like that so that it is very clearly not a 
"subtype" field.

If it were not needed to process options for these ICMP types, then I 
think the ICMP length in the next header field would suffice.

Another possibility would be to reserve some initial bits of the ROVR 
field itself to indicate the length of the ROVR.   Old-legacy nodes 
would still discard new DAR and DAC messages with a ROVR that was too 
long.  New-legacy nodes would know to check the first three or four bits 
of the field for the length of the ROVR.  But I did not think this all 
the way through yet.

Regards,
Charlie P.