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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Charlie:


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

Yes :)
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.


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?

Yes; there is no room for that field and even the ROVR type is somewhat lacking


  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.


Well, old legacy Ignore the ICMP code so that much is not a requirement. But then they support only ROVR size of 64 bits.
The situation of a legacy can be discovered with our spec and there is always the fallback situation of avoiding new incompatible stuff.

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

Yes, and even better would have been more room for a ROVR type too.


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.


This is why I carved 4 bits, yes.

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.

Maybe a future non compatible format will use it differently in a situation with no new legacy device. I’d prefer indicating both; it is a sub code and it indicates the ROVR size.


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.


Agreed but an option is already coming up for using DAR DAC on the backbone. Anyway an inextensible message would be a great waste of ICMP space.

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.


But old legacy will set those bits randomly. And then we have alignment problems. I proposed the subcode as a last resort...

Take care,

Pascal

Regards,
Charlie P.