Re: [PATCH net-next v4 0/5] Support for the IOAM Pre-allocated Trace with IPv6

[David Ahern <dsahern@gmail.com>]

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.