brockners
commented
6 years ago On (2.): Per the discussion on the IPPM list, text should be added which states that either the short or the long version of a data field is used, but never both at the same time
For reference (quote from the mailing list discussion):
2. Regardless bit[7], when all bits are set where some are short and some are wide, the current total is 14 where we have spare of 4 bits (12-15). If they will be used this field will not be able to show the total node length
Without considering bit[7], looking at the current bits there should be no need for any combination with length greater than 11. Why would anyone need both short (4-octets) and wide (8-octets) fields of Hop_Lim and Node_id? Or both short and wide fields of ingress_if_id and egress_if_id? Or both short and wide fields of app_data?
Agree that it is not reasonable to use both short and wide, it should be documented to restrict it. For the other bits that are now reserved 12-15 (4 bits) we could reach to 15 which is the maximum value of this field. In case one of them will be defined as wide without a short version we will exceed the width of the field.
NodeLen described as the total length of data needed to be added by each node. It contains 4bits in 4B resolution which means 4B up to 60B.
The issues we see with this are: 1. There is no reference to bit[7] which has variable length.
2. Regardless bit[7], when all bits are set where some are short and some are wide, the current total is 14 where we have spare of 4 bits (12-15). If they will be used this field will not be able to show the total node length
3. Even of all the above are solved, checks needs to be defined in case the NodeLen is not matching the number of bits in the trace type. Suggest to add text that trace type has precedence and if a node decides to use the NodeLen it is required to do checks on the trace type.