Re: [ippm] [spring] FW: New Version Notification for draft-filsfils-spring-path-tracing-05.txt

Hi Ahmed and Authors,
thank you for the update on the evolution of this work. I've read the
latest version and have several questions. I greatly appreciate your kind
consideration:

   - As I understand it, the motivation for this work is the
   perceived overhead of some on-path telemetry methods:

   The overhead [of Path Tracing] is lower than [INT], [RFC9197],
   [I-D.song-opsawg-ifit-framework], and [I-D.kumar-ippm-ifa].

I find that statement too general and, as a result, not technically
accurate. Both INT and IOAM support not only "in-packet" method of
collecting and transporting generated on a node operational state and
telemetry information, but also a mode (e.g., RFC 9326 IOAM Direct Expor
<https://datatracker.ietf.org/doc/rfc9326/>t) in which such information is
exported according to a local policy, e.g., using IPFIX or another
management bus. If my understanding is correct, what could be the benefit
of standardizing the Path Tracing?

   - Also, while comparing the network efficiency of an on-path telemetry
   methods, how, in the authors opinion, the density and informational
   reachness of the Path Tracing can be compared with the HPCC++ proposal
   <https://datatracker.ietf.org/doc/html/draft-miao-iccrg-hpccplus-01>?
   - The document requires that all nodes use a clock synchronization
   mechanism. Do you see a need to specify the quality of clock
   synchronization in an RT domain?
   - Upon finishing reading the draft, I find myself a bit surprised that
   it does not reference RFC 9341
   <https://datatracker.ietf.org/doc/rfc9341/> Alternate-Marking Method.
   What are the authors thoughts about the AMM compared to RT?

Regards,
Greg

On Wed, Oct 25, 2023 at 5:20 AM Ahmed Abdelsalam (ahabdels) <ahabdels=
40cisco.com@dmarc.ietf.org> wrote:

> Dear SPRING WG,
>
>
>
> We have submitted a new revision of draft-filsfils-spring-path-tracing.
>
>
>
> The previous revisions of the draft defined an SRH TLV and an IPv6
> Hop-by-Hop Option for Path Tracing.
>
> Based on received feedback we have replaced the SRH TLV with an IPv6
> Destination Option.
>
>
>
> The draft was last presented at IETF 113. The Hop-by-Hop option has
> running-code across 5 different ASICs from different vendors (all
> implementations are at linerate); in addition to the FD.io VPP and Linux
> Kernel opensource implementations. More info in Section 5 of the draft.
>
>
>
> We look forward to the WG review and feedback.
>
>
>
> Thanks
>
> Ahmed
>
>
>
> *From: *internet-drafts@ietf.org <internet-drafts@ietf.org>
> *Date: *Monday, 23 October 2023 at 17:56
> *To: *Ahmed Abdelsalam (ahabdels) <ahabdels@cisco.com>, Amit Dhamija <
> amitd@arrcus.com>, cf(mailer list) <cf@cisco.com>, Dhamija <
> amitd@arrcus.com>, Mark Yufit <mark.yufit@broadcom.com>, Mike Valentine <
> michael.j.valentine@gs.com>, Pablo Camarillo (pcamaril) <
> pcamaril@cisco.com>, Pablo Camarillo (pcamaril) <pcamaril@cisco.com>,
> Satoru Matsushima <satoru.matsushima@g.softbank.co.jp>, Thomas Graf <
> thomas.graf@swisscom.com>, Yuanchao Su <yitai.syc@alibaba-inc.com>
> *Subject: *New Version Notification for
> draft-filsfils-spring-path-tracing-05.txt
>
> A new version of Internet-Draft draft-filsfils-spring-path-tracing-05.txt
> has
> been successfully submitted by Ahmed Abdelsalam and posted to the
> IETF repository.
>
> Name:     draft-filsfils-spring-path-tracing
> Revision: 05
> Title:    Path Tracing in SRv6 networks
> Date:     2023-10-23
> Group:    Individual Submission
> Pages:    18
> URL:
> https://www.ietf.org/archive/id/draft-filsfils-spring-path-tracing-05.txt
> Status:
> https://datatracker.ietf.org/doc/draft-filsfils-spring-path-tracing/
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-filsfils-spring-path-tracing-05
>
> Abstract:
>
>    Path Tracing provides a record of the packet path as a sequence of
>    interface ids.  In addition, it provides a record of end-to-end
>    delay, per-hop delay, and load on each egress interface along the
>    packet delivery path.
>
>    Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop-
>    by-Hop extension header.
>
>    Path Tracing supports fine grained timestamp.  It has been designed
>    for linerate hardware implementation in the base pipeline.
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>