| Message ID | 20210527151652.16074-1-justin.iurman@uliege.be (mailing list archive) |
|---|---|
| Headers | show |
| Series | Support for the IOAM Pre-allocated Trace with IPv6 | expand |
On 5/27/21 9:16 AM, Justin Iurman wrote: > v4: > - Address warnings from checkpatch (ignore errors related to unnamed bitfields > in the first patch) > - Use of hweight32 (thanks Jakub) > - Remove inline keyword from static functions in C files and let the compiler > decide what to do (thanks Jakub) > > v3: > - Fix warning "unused label 'out_unregister_genl'" by adding conditional macro > - Fix lwtunnel output redirect bug: dst cache useless in this case, use > orig_output instead > > v2: > - Fix warning with static for __ioam6_fill_trace_data > - Fix sparse warning with __force when casting __be64 to __be32 > - Fix unchecked dereference when removing IOAM namespaces or schemas > - exthdrs.c: Don't drop by default (now: ignore) to match the act bits "00" > - Add control plane support for the inline insertion (lwtunnel) > - Provide uapi structures > - Use __net_timestamp if skb->tstamp is empty > - Add note about the temporary IANA allocation > - Remove support for "removable" TLVs > - Remove support for virtual/anonymous tunnel decapsulation > > In-situ Operations, Administration, and Maintenance (IOAM) records > operational and telemetry information in a packet while it traverses > a path between two points in an IOAM domain. It is defined in > draft-ietf-ippm-ioam-data [1]. IOAM data fields can be encapsulated > into a variety of protocols. The IPv6 encapsulation is defined in > draft-ietf-ippm-ioam-ipv6-options [2], via extension headers. IOAM > can be used to complement OAM mechanisms based on e.g. ICMP or other > types of probe packets. > > This patchset implements support for the Pre-allocated Trace, carried > by a Hop-by-Hop. Therefore, a new IPv6 Hop-by-Hop TLV option is > introduced, see IANA [3]. The three other IOAM options are not included > in this patchset (Incremental Trace, Proof-of-Transit and Edge-to-Edge). > The main idea behind the IOAM Pre-allocated Trace is that a node > pre-allocates some room in packets for IOAM data. Then, each IOAM node > on the path will insert its data. There exist several interesting use- > cases, e.g. Fast failure detection/isolation or Smart service selection. > Another killer use-case is what we have called Cross-Layer Telemetry, > see the demo video on its repository [4], that aims to make the entire > stack (L2/L3 -> L7) visible for distributed tracing tools (e.g. Jaeger), > instead of the current L5 -> L7 limited view. So, basically, this is a > nice feature for the Linux Kernel. > > This patchset also provides support for the control plane part, but only for the > inline insertion (host-to-host use case), through lightweight tunnels. Indeed, > for in-transit traffic, the solution is to have an IPv6-in-IPv6 encapsulation, > which brings some difficulties and still requires a little bit of work and > discussion (ie anonymous tunnel decapsulation and multi egress resolution). > > - Patch 1: IPv6 IOAM headers definition > - Patch 2: Data plane support for Pre-allocated Trace > - Patch 3: IOAM Generic Netlink API > - Patch 4: Support for IOAM injection with lwtunnels > - Patch 5: Documentation for new IOAM sysctls > > [1] https://tools.ietf.org/html/draft-ietf-ippm-ioam-data > [2] https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options > [3] https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2 > [4] https://github.com/iurmanj/cross-layer-telemetry > These are draft documents from February 2021. Good to have RFC patches for others to try the proposed feature, but is really early to be committing code to Linux. I think we should wait and see how that proposal develops.
Hi David, > On 5/27/21 9:16 AM, Justin Iurman wrote: >> v4: >> - Address warnings from checkpatch (ignore errors related to unnamed bitfields >> in the first patch) >> - Use of hweight32 (thanks Jakub) >> - Remove inline keyword from static functions in C files and let the compiler >> decide what to do (thanks Jakub) >> >> v3: >> - Fix warning "unused label 'out_unregister_genl'" by adding conditional macro >> - Fix lwtunnel output redirect bug: dst cache useless in this case, use >> orig_output instead >> >> v2: >> - Fix warning with static for __ioam6_fill_trace_data >> - Fix sparse warning with __force when casting __be64 to __be32 >> - Fix unchecked dereference when removing IOAM namespaces or schemas >> - exthdrs.c: Don't drop by default (now: ignore) to match the act bits "00" >> - Add control plane support for the inline insertion (lwtunnel) >> - Provide uapi structures >> - Use __net_timestamp if skb->tstamp is empty >> - Add note about the temporary IANA allocation >> - Remove support for "removable" TLVs >> - Remove support for virtual/anonymous tunnel decapsulation >> >> In-situ Operations, Administration, and Maintenance (IOAM) records >> operational and telemetry information in a packet while it traverses >> a path between two points in an IOAM domain. It is defined in >> draft-ietf-ippm-ioam-data [1]. IOAM data fields can be encapsulated >> into a variety of protocols. The IPv6 encapsulation is defined in >> draft-ietf-ippm-ioam-ipv6-options [2], via extension headers. IOAM >> can be used to complement OAM mechanisms based on e.g. ICMP or other >> types of probe packets. >> >> This patchset implements support for the Pre-allocated Trace, carried >> by a Hop-by-Hop. Therefore, a new IPv6 Hop-by-Hop TLV option is >> introduced, see IANA [3]. The three other IOAM options are not included >> in this patchset (Incremental Trace, Proof-of-Transit and Edge-to-Edge). >> The main idea behind the IOAM Pre-allocated Trace is that a node >> pre-allocates some room in packets for IOAM data. Then, each IOAM node >> on the path will insert its data. There exist several interesting use- >> cases, e.g. Fast failure detection/isolation or Smart service selection. >> Another killer use-case is what we have called Cross-Layer Telemetry, >> see the demo video on its repository [4], that aims to make the entire >> stack (L2/L3 -> L7) visible for distributed tracing tools (e.g. Jaeger), >> instead of the current L5 -> L7 limited view. So, basically, this is a >> nice feature for the Linux Kernel. >> >> This patchset also provides support for the control plane part, but only for the >> inline insertion (host-to-host use case), through lightweight tunnels. Indeed, >> for in-transit traffic, the solution is to have an IPv6-in-IPv6 encapsulation, >> which brings some difficulties and still requires a little bit of work and >> discussion (ie anonymous tunnel decapsulation and multi egress resolution). >> >> - Patch 1: IPv6 IOAM headers definition >> - Patch 2: Data plane support for Pre-allocated Trace >> - Patch 3: IOAM Generic Netlink API >> - Patch 4: Support for IOAM injection with lwtunnels >> - Patch 5: Documentation for new IOAM sysctls >> >> [1] https://tools.ietf.org/html/draft-ietf-ippm-ioam-data >> [2] https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options >> [3] >> https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2 >> [4] https://github.com/iurmanj/cross-layer-telemetry >> > > These are draft documents from February 2021. Good to have RFC patches > for others to try the proposed feature, but is really early to be > committing code to Linux. I think we should wait and see how that > proposal develops. Actually, February 2021 is the last update. The main draft (draft-ietf-ippm-ioam-data) has already come a long way (version 12) and has already been Submitted to IESG for Publication. I don't think it would hurt that much to have it in the kernel as we're talking about a stable draft (the other one is just a wrapper to define the encapsulation of IOAM with IPv6) and something useful. And, if you think about Segment Routing for IPv6, it was merged in the kernel when it was still a draft. Justin
On Thu, 27 May 2021 17:16:47 +0200 Justin Iurman wrote: > In-situ Operations, Administration, and Maintenance (IOAM) records > operational and telemetry information in a packet while it traverses > a path between two points in an IOAM domain. It is defined in > draft-ietf-ippm-ioam-data [1]. IOAM data fields can be encapsulated > into a variety of protocols. The IPv6 encapsulation is defined in > draft-ietf-ippm-ioam-ipv6-options [2], via extension headers. IOAM > can be used to complement OAM mechanisms based on e.g. ICMP or other > types of probe packets. > > This patchset implements support for the Pre-allocated Trace, carried > by a Hop-by-Hop. Therefore, a new IPv6 Hop-by-Hop TLV option is > introduced, see IANA [3]. The three other IOAM options are not included > in this patchset (Incremental Trace, Proof-of-Transit and Edge-to-Edge). > The main idea behind the IOAM Pre-allocated Trace is that a node > pre-allocates some room in packets for IOAM data. Then, each IOAM node > on the path will insert its data. There exist several interesting use- > cases, e.g. Fast failure detection/isolation or Smart service selection. > Another killer use-case is what we have called Cross-Layer Telemetry, > see the demo video on its repository [4], that aims to make the entire > stack (L2/L3 -> L7) visible for distributed tracing tools (e.g. Jaeger), > instead of the current L5 -> L7 limited view. So, basically, this is a > nice feature for the Linux Kernel. Some coding comments from me. Please continue the discussion with David re: maturity of the RFC and make sure to CC him and Yoshifuji on next versions.
> On Thu, 27 May 2021 17:16:47 +0200 Justin Iurman wrote: >> In-situ Operations, Administration, and Maintenance (IOAM) records >> operational and telemetry information in a packet while it traverses >> a path between two points in an IOAM domain. It is defined in >> draft-ietf-ippm-ioam-data [1]. IOAM data fields can be encapsulated >> into a variety of protocols. The IPv6 encapsulation is defined in >> draft-ietf-ippm-ioam-ipv6-options [2], via extension headers. IOAM >> can be used to complement OAM mechanisms based on e.g. ICMP or other >> types of probe packets. >> >> This patchset implements support for the Pre-allocated Trace, carried >> by a Hop-by-Hop. Therefore, a new IPv6 Hop-by-Hop TLV option is >> introduced, see IANA [3]. The three other IOAM options are not included >> in this patchset (Incremental Trace, Proof-of-Transit and Edge-to-Edge). >> The main idea behind the IOAM Pre-allocated Trace is that a node >> pre-allocates some room in packets for IOAM data. Then, each IOAM node >> on the path will insert its data. There exist several interesting use- >> cases, e.g. Fast failure detection/isolation or Smart service selection. >> Another killer use-case is what we have called Cross-Layer Telemetry, >> see the demo video on its repository [4], that aims to make the entire >> stack (L2/L3 -> L7) visible for distributed tracing tools (e.g. Jaeger), >> instead of the current L5 -> L7 limited view. So, basically, this is a >> nice feature for the Linux Kernel. > > Some coding comments from me. Please continue the discussion with David > re: maturity of the RFC and make sure to CC him and Yoshifuji on next > versions. I'll do that. Thanks again for your review. Justin
On 5/29/21 10:24 AM, Justin Iurman wrote:
> Actually, February 2021 is the last update. The main draft (draft-ietf-ippm-ioam-data) has already come a long way (version 12) and has already been Submitted to IESG for Publication. I don't think it would hurt
when the expected decision on publication?
that much to have it in the kernel as we're talking about a stable
draft (the other one is just a wrapper to define the encapsulation of
IOAM with IPv6) and something useful. And, if you think about Segment
Routing for IPv6, it was merged in the kernel when it was still a draft.
The harm is if there are any changes to the uapi.
>> Actually, February 2021 is the last update. The main draft >> (draft-ietf-ippm-ioam-data) has already come a long way (version 12) and has >> already been Submitted to IESG for Publication. I don't think it would hurt > > when the expected decision on publication? Hard to tell precisely, a couple weeks probably. There are still some comment/discuss to clear and our next IETF working group meeting is in July. However, it shouldn't be a concern (see below). > that much to have it in the kernel as we're talking about a stable > draft (the other one is just a wrapper to define the encapsulation of > IOAM with IPv6) and something useful. And, if you think about Segment > Routing for IPv6, it was merged in the kernel when it was still a draft. > > The harm is if there are any changes to the uapi. Definitely agree. But, I can assure you there won't be any uapi change at this stage. None of the comment/discuss I mentioned above are about this at all. Headers definition and IANA codes are defined for a long time now and won't change anymore.
On 5/31/21 6:04 AM, Justin Iurman wrote: >>> Actually, February 2021 is the last update. The main draft >>> (draft-ietf-ippm-ioam-data) has already come a long way (version 12) and has >>> already been Submitted to IESG for Publication. I don't think it would hurt >> >> when the expected decision on publication? > > Hard to tell precisely, a couple weeks probably. There are still some comment/discuss to clear and our next IETF working group meeting is in July. However, it shouldn't be a concern (see below).\ Ok. > >> that much to have it in the kernel as we're talking about a stable >> draft (the other one is just a wrapper to define the encapsulation of >> IOAM with IPv6) and something useful. And, if you think about Segment >> Routing for IPv6, it was merged in the kernel when it was still a draft. >> >> The harm is if there are any changes to the uapi. > > Definitely agree. But, I can assure you there won't be any uapi change at this stage. None of the comment/discuss I mentioned above are about this at all. Headers definition and IANA codes are defined for a long time now and won't change anymore. > Please add tests to tools/testing/selftests/net to cover the functionality added.