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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210529141016.4015a396@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Sat, 29 May 2021 14:10:16 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Justin Iurman <justin.iurman@...ege.be>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, tom@...bertland.com
Subject: Re: [PATCH net-next v4 0/5] Support for the IOAM Pre-allocated
 Trace with IPv6

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.