[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1049853171.33683948.1622305441066.JavaMail.zimbra@uliege.be>
Date: Sat, 29 May 2021 18:24:01 +0200 (CEST)
From: Justin Iurman <justin.iurman@...ege.be>
To: David Ahern <dsahern@...il.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
tom@...bertland.com, Iurman Justin <Justin.Iurman@...ege.be>
Subject: Re: [PATCH net-next v4 0/5] Support for the IOAM Pre-allocated
Trace with IPv6
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
Powered by blists - more mailing lists