Re: [ippm] NodeLen in In-situ OAM trace option

[Mickey Spiegel <[e-mail]>]

On Sat, Aug 19, 2017 at 11:43 PM, Aviv Kfir <[e-mail]> wrote:

> Hi All,
>
>
>
> 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.
>
>
>
> I see few issues with this field and want to open it to a discussion.
>
>
>
> 1.
>
> There is no consideration to bit[7] "Opaque State Snapshot" which has
> variable length
>

This points out that there is some ambiguity with respect to the meaning of
bit[7]. When bit[7] is set, this indicates that some "opaque state" must be
included in the IOAM trace node data list, but it does not indicate what
"opaque state" is intended to be captured. If there is more than one
possible "opaque state" field (i.e. more than one schema is supported),
then the node must determine which one to insert locally, perhaps based on
configuration.

If it is desired to keep the "Opaque State Snapshot" despite this issue,
then the NodeLen could be defined as the length of data added by each node
in multiples of 4-octets, excluding the length of the "Opaque State
Snapshot". If bit[7] is not set, then the NodeLen specifies the actual
length added by each node. If bit[7] is set, then the actual length added
by a node would be (NodeLen + Opaque Data Length), assuming that the Opaque
Data Length is changed to units of multiples of 4-octets.

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?


> 3.
>
> 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 field has precedence and if a node
> decides to use the NodeLen it is required to do checks on the trace type.
>

This defeats the purpose of adding this field. In-situ OAM is designed to
record information within data packets, without significantly affecting the
processing of those data packets. As such, it is important that it be
specified in a manner that is hardware friendly.

By including the NodeLen, it eases the task of data plane processing. While
inclusion of node data fields must be driven only by the IOAM-Trace-Type
bits, it is also necessary to determine the length of data added by each
node. This length is used both to determine whether the Maximum Length
would be exceeded, and to adjust the length of encapsulating headers.

IOAM is meant to be used within a "network domain" operated by a single
administration. The IOAM administrator would specify the node data fields
that are desired. Nodes at the edge of the network domain insert the
appropriate IOAM Trace Option with the set of bits corresponding to the
node data fields specified by the IOAM administrator. A software driver can
determine the NodeLen based on the set of bits, i.e. the NodeLen is not
meant to be a user configurable field. NodeLen is just a value that can be
precomputed and communicated to each node along the path, easing the burden
of per packet data plane processing.

There have been offline suggestions that a translation table could be used
to determine this length, without having to do the arithmetic associated
with the individual bits. The issue with such an approach is that the
number of possible combinations is likely to be large. If only a subset of
combinations were to be included in the translation table, then this would
add an operational burden. The IOAM administrator would have to specify the
allowed combinations before the feature could be enabled, making IOAM more
difficult to use.

Mickey


>
> Thanks,
>
> Aviv
>