Data draft: IOAM-Trace-Type Bit 12-22 must be zero - why not simply ignore it

[brockners]

https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs

"
Bit 12-22 Undefined. An IOAM encapsulating node must set the
value of each of these bits to 0. If an IOAM transit
node receives a packet with one or more of these bits set
to 1, it must either:
"
Why not directly ignore these bits which are not set as 0?

Note: Reserved unused bits can be expected to be Zero to help backward compatible implementation especially when the setting the bit changes the way data following it needs to be interpreted

[mickeyspiegel]

This is due to #63.

Say we release version IOAM data version 1, then later on we release IOAM data version 1.1 that assigns a meaning to one of the previously unused trace type bits. If the encapsulating node and the collector that ultimately receives all the collected IOAM metadata support version 1.1, and the new trace type is set, then they will expect each hop to add the corresponding field. If there is a transit node that only supports version 1.0 and does not understand the new trace type bit, and it ignores the bit and adds less than NodeLen words to the packet, then the collector will not be able to parse the packet correctly. As the packet traverses the network, the metadata is being prepended one field at a time as a stack, with no explicit identifier which field is which. The collector can figure out which field is which only if it knows how much metadata each node added.

[mickeyspiegel]

Actually I don't think #119 addresses this. I could not find anything.

I don't think this needs to be addressed, as per my explanation above. IMO the text in the draft is clear. It does not explain why, but typically we do not explain why.

[brockners]

Hi Mickey, I agree that #119 does not address this topic - my bad, I inserted the wrong reference in the commit message. I also agree that there is no need for further edits to the draft based on your comment above.