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

From: Aviv Kfir <[email-masked]>
Date: Sun, 20 Aug 2017 06:43:19 +0000

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

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.
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.

Thanks,
Aviv

---

From: Mickey Spiegel <[email-masked]>
Date: Sun, 20 Aug 2017 23:55:57 -0700

> There is no consideration to bit[7] "Opaque State Snapshot" which has

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?

> 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

---

From: Aviv Kfir <[email-masked]>
Date: Tue, 29 Aug 2017 15:24:24 +0000

From: Mickey Spiegel [mailto:[email-masked]]
Sent: Monday, August 21, 2017 9:56 AM
To: Aviv Kfir <[email-masked]>
Cc: [email-masked]
Subject: Re: [ippm] NodeLen in In-situ OAM trace option

On Sat, Aug 19, 2017 at 11:43 PM, Aviv Kfir <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

1.

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.

Agree, just need to document that it does not include the variable length opaque length.

2.

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.

3.

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.

I understand and agree that it improves data-path processing, maybe we should document that it is up to the implementation if to use this field or calculate it from the bit-vector.

Mickey

Thanks,
Aviv

---

From: Aviv Kfir <[email-masked]>
Date: Wed, 30 Aug 2017 15:50:46 +0000

From: Aviv Kfir
Sent: Tuesday, August 29, 2017 6:24 PM
To: 'Mickey Spiegel' <[email-masked]>
Cc: [email-masked]
Subject: RE: [ippm] NodeLen in In-situ OAM trace option

From: Mickey Spiegel [mailto:[email-masked]]
Sent: Monday, August 21, 2017 9:56 AM
To: Aviv Kfir <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [ippm] NodeLen in In-situ OAM trace option

1.

2.

[AK] Adding additional bit to the node-length field makes it more future compatible. We can take the additional bit from the flag field
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.

[AK] We can say that this field is mandatory when a node creates the initial header, it is up to the transit node implementation whether to use it or rely on the bit-vector.

Mickey

Thanks,
Aviv

---

From: Mickey Spiegel <[email-masked]>
Date: Thu, 31 Aug 2017 00:57:16 -0700

On Wed, Aug 30, 2017 at 8:50 AM, Aviv Kfir <[email-masked]> wrote:

>
>
>
>
> *From:* Aviv Kfir
> *Sent:* Tuesday, August 29, 2017 6:24 PM
> *To:* 'Mickey Spiegel' <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: [ippm] NodeLen in In-situ OAM trace option
>
>
>
>
>
>
>
> *From:* Mickey Spiegel [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Monday, August 21, 2017 9:56 AM
> *To:* Aviv Kfir <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [ippm] NodeLen in In-situ OAM trace option
>
>
>
>
>
> 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

Agreed.

> 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.
>
> *[AK] Adding additional bit to the node-length field makes it more future
> compatible. We can take the additional bit from the flag field*
>

I am not sure what other uses people have in mind for the Flags field. I
have no objections to this.

> 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.
>
>
>
> I understand and agree that it improves data-path processing, maybe we
> should document that it is up to the implementation if to use this field or
> calculate it from the bit-vector.
>
>
>
> *[AK] We can say that this field is mandatory when a node creates the
> initial header, it is up to the transit node implementation whether to use
> it or rely on the bit-vector.*
>

That works for me.

Mickey