Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)

[Tal Mizrahi <[e-mail]>]

Hi Ben,

The authors further discussed the issue below, regarding the length of
future data fields. After further discussion we suggest to mandate
future data fields to be 4-octets long.
Therefore, we suggest the following text update:

OLD:
      Bit 12-21  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:
NEW:
      Bit 12-21  Undefined. These values are available for future
               assignment in the IOAM Trace-Type Registry (Section 8.2).
               Every future node data field corresponding to one of these
               bits MUST be 4-octets long.
               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:

Please let us know if you have further comments.

Thanks,
Tal.


On Tue, May 4, 2021 at 9:16 PM Frank Brockners (fbrockne)
<[e-mail]> wrote:
> >
> >       Bit 12-21  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:
> >
> >                1.  Add corresponding node data filled with the reserved
> >                    value 0xFFFFFFFF, after the node data fields for the
> >                    IOAM-Trace-Type bits defined above, such that the
> >
> > Just to confirm: this means that there cannot be any future allocations of bits to
> > "wide format" items and thus that only bits 8-10 will ever consume 2 units each
> > of four-octets?  (This does not preclude allocating two adjacent bits to indicate
> > a single logical data item, of course, with appropriate error handling for when
> > only one of the two is set.)
>
> ...FB: Another good catch - and excluding future allocations in "wide" format wasn't the intention from what I know. To simplify things, we can avoid the "either" behavior and simply state:
>
>       Bit 12-21  Undefined, see section 8.2. for future registrations.
>
>                An IOAM encapsulating node MUST set the
>                value of each reserved bit to 0.  If an IOAM transit
>                node receives a packet with one or more of the reserved bits set
>                to 1, it MUST not add any node data fields to the packet, even for
>                the IOAM-Trace-Type bits defined above.
>
> >
> >       Bit 23   Reserved: MUST be set to zero upon transmission and
> >                ignored upon receipt.