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: <1297213235.34113426.1622371798604.JavaMail.zimbra@uliege.be>
Date:   Sun, 30 May 2021 12:49:58 +0200 (CEST)
From:   Justin Iurman <justin.iurman@...ege.be>
To:     Jakub Kicinski <kuba@...nel.org>
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.

I'll do that. Thanks again for your review.

Justin