Re: [ippm] on supporting IOAM in IPv6

On Wed, Jul 15, 2020 at 11:17 AM Haoyu Song <haoyu.song@futurewei.com> wrote:
>
> Hi all,
>
>
>
> We will present this draft in the lighting talk session of IPPM WG meeting in IETF108
>
> https://datatracker.ietf.org/doc/draft-song-ippm-ioam-ipv6-support/
>
>
>
> Since there is usually no time for any discussion for the short talk in the meeting, we’d like to start this email discussion thread, also involving the relevant 6man WG, to solicit suggestions and comments.
>
> Below is a quick summary:
>
>
>
> The draft is related to another WG draft https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/ in which the IOAM trace option is proposed to be carried as an IPv6 HBH option..
>
>
>
> However, using HBH, the mandatory first extension header,  to carry the large and potentially variable size IOAM trace option can be very challenging for implementations,
>

> especially when some other extension headers, such as SRv6 RH, must be accessed.
>
Haoyu,

>From the draft:

"There are practical limitations on how far the hardware can reach
into a packet in forwarding hardware."

Can you quantify these limitations? For instance, the draft is
concerned about large headers, but what exactly is a "large header".
In other words can you assign the number of bytes of headers for which
we can expect hardware to be able to generally process, and so only
when the length of headers exceeds that particular number do we need
to consider alternative mechanisms?

Also:
"A potentially more detrimental issue is that the incremental tracing
option will expand the HbH header at each hop and push back all other
headers, which keeps shifting the locations of the other extension
headers, further complicating the hardware implementation and impeding
the forwarding."

Changing the size of the HBH header inflight is currently prohibited
by RFC8200 (see draft-herbert-6man-eh-attrib-01 for how this might be
done safely). But even if this is done, it doesn't seem like it
changes the problem statement that a node can't process a packet if
the necessary headers don't fit into it's parsing buffer.

Tom

>
>
> This draft discuss several alternatives to avoid or mitigate the problem, including:
>
> Separate the header part and data part of the IOAM trace option, and move the data part to a later extension header while keeping the header part in HBH
> Using the IOAM DEX option instead to avoid carrying data in packet
> Using the segment IOAM trace method to ensure the IOAM data will be stripped off and exported at some specific nodes (e.g., SRv6 segments),  so the IOAM option header can remain short and constant at these nodes.
>
> Flavor 1: Fixed segment size encoded in IOAM option header
> Flavor 2: Configurable by network controller
>
>
>
> Please see more detailed description in the draft. The draft only covers the IOAM-related methods, although other methods are also possible.
>
>
>
> Please let us know what you think. Thank you very much!
>
>
>
> Best regards,
>
> Haoyu
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm