Subject: on supporting IOAM in IPv6

From: Haoyu Song <[email-masked]>
Date: Wed, 15 Jul 2020 18:16:07 +0000

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.

This draft discuss several alternatives to avoid or mitigate the problem, including:

  1.  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
  2.  Using the IOAM DEX option instead to avoid carrying data in packet
  3.  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

---

From: Tom Herbert <[email-masked]>
Date: Wed, 15 Jul 2020 11:51:54 -0700

On Wed, Jul 15, 2020 at 11:17 AM Haoyu Song <[email-masked]> wrote:
> 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.
>
> 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..
>
>
>

> 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

> 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
>
>
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Haoyu Song <[email-masked]>
Date: Thu, 16 Jul 2020 04:51:57 +0000

Inline

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Wednesday, July 15, 2020 11:52 AM
To: Haoyu Song <[email-masked]>
Cc: IETF IPPM WG ([email-masked]) <[email-masked]>; 6man <[email-masked]>
Subject: Re: [ippm] on supporting IOAM in IPv6

On Wed, Jul 15, 2020 at 11:17 AM Haoyu Song <[email-masked]> wrote:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-song-ippm-ioam-ipv6-support%2F&amp;data
> =02%7C01%7Chaoyu.song%40futurewei.com%7C020546892f684e4aefba08d828f02c
> 74%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637304359290829424&amp
> ;sdata=cN3%2Fh77DZnCkhFj%2BGNr%2BVRpva5tER%2FUKhYYKdBjEYWU%3D&amp;rese
> rved=0
>
>
>
> The draft is related to another WG draft https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-ipv6-options%2F&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C020546892f684e4aefba08d828f02c74%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637304359290829424&amp;sdata=cEFdGgkLetlbHsoP8m3KAosEf7Ib5Qr3mRxcz%2Fk32%2F0%3D&amp;reserved=0 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,
>

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?

[HS] IOAM option's basic header part is 8B, plus 8B to 32B (or more) data per hop. For a ~10 hop network, the overhead amounts to one to a few hundred bytes.
For the commercial chips, I have seen the total packet parser depth ranges from 128B to 512B.
For NPs, theoretically we  don't have a parse depth limit. But up to some extent, we need to shift and load the new packet window from memory, which can considerably lower the forwarding performance.  
Other people may provide more data about this. The current IOAM option overhead is pushing the envelope,  especially when other extension headers or options exist.  

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.

[HS] I didn't realize that constraint. It means at least the incremental tracing option is more problematic. 

Tom

> 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
>
>
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data=02%7C01%7Chaoyu.song%40f
> uturewei.com%7C020546892f684e4aefba08d828f02c74%7C0fee8ff2a3b240189c75
> 3a1d5591fedc%7C1%7C0%7C637304359290829424&amp;sdata=o%2F%2FTgx1ICgACgz
> fylFQqlIG6zfRmz7QWZPBhtPieCo0%3D&amp;reserved=0