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

Greg Mirsky <> Tue, 15 March 2022 01:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15D263A1588; Mon, 14 Mar 2022 18:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wb2hX4DLlChp; Mon, 14 Mar 2022 18:25:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CAB63A158C; Mon, 14 Mar 2022 18:25:14 -0700 (PDT)
Received: by with SMTP id y15so5357819qta.13; Mon, 14 Mar 2022 18:25:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5hyVnaRMmdfE//0IL+QN8b2hgqPiTLvbYYPhCLBASiw=; b=q09W98Bf+Tss9l6zpaC40PG30Qx8H6pydKqjHFWyrYHIvEW6Vbn9uorgnSEVyQQyhW xMDoJcXN2+vrdOWfoM65K1fjGltGH4H7/bq1ClLrsm0tUuOATZw/6QQZMh2p+cI54JBa QMnXmzcUTyq0FZv02cg7pOOEQ+uI0UQCU29dV/csycGyTFsbZc77TMeRzRTqJpfErVW8 XfmBGci9Eh1TJOFImXb2F2+pG8eQlaY6KSd0YOxmHa23OFREF8MKjNLl/dQAxR9oGkMj SawRm/S8/knJu4K5v//CRCK1V5++cklXYTfK/syMYHfowHCJI/7AGm4zrB0lSIRfGC7a beqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5hyVnaRMmdfE//0IL+QN8b2hgqPiTLvbYYPhCLBASiw=; b=IMDRXmHbF6q8bUVXZqUbPaulPtyAJs7TmXUnLmTWOqeJJaXs55yGOKFw/EX/Mlneiw SmFb55whdMJ9ScKn8piA7fIwXfypPpjJK9SWjt7wTHcWtr1p20Cx+jcYuwwTvZ3AYvPW i4UheE4PMZ4JZ1T4XYFB6hI2Mhjnj+p0dnc/nmdew6CLLHOLXH5/mT6O/MYzR66Q6OS2 QKeWt/pZGmVpr033UjixZxaLeHV8IDl3stcGIgJW9oaiOq89hQZT/3zJu64CM37W3znH TI9UD4mpDVj/p1mf6v3cgZHZpchYwAoGZHHzXqwXWlWCSoaQK0WrUdAHkx+UpB3B0Fjl 26/w==
X-Gm-Message-State: AOAM5300tds6yKWWbQsGlVp1QUgzsbdIRUVG+MpT5cNo1YrNPu2PlgQI B7cvHoo7SZ4pFkn9EV07VOkYaQ4oOyWIi2E6ICTuFCFCQ9M=
X-Google-Smtp-Source: ABdhPJy8K0j8ia3VzV27EXfUDhr9J/8EFha7DLojFwV1wos4A+D/kO5RkUQr+GpmcZlsAjoxYUr8JK3TBGqTLraNSVI=
X-Received: by 2002:a05:622a:189e:b0:2e1:dcd4:d01c with SMTP id v30-20020a05622a189e00b002e1dcd4d01cmr3122549qtc.1.1647307512806; Mon, 14 Mar 2022 18:25:12 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Mon, 14 Mar 2022 18:25:01 -0700
Message-ID: <>
To: "Ahmed Abdelsalam (ahabdels)" <>,
Cc: "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000023015c05da37abca"
Archived-At: <>
Subject: Re: [ippm] FW: New Version Notification for draft-filsfils-spring-path-tracing-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Mar 2022 01:25:22 -0000

Hi Ahmed and the Authors,
thank you for sharing this information. I've read the draft and have
several questions and comments:

   - It is not clear if you propose a new active measurement protocol or
   view it as a hybrid method (based on RFC 7799 classification). On one hand,
   packets are referred to as probes, but I don't see why the new Hb H option
   cannot be applied to a data packet.
   - Resemblance with IOAM is very strong and it seems that the only
   advantage of PT over IOAM seems in the introduction of a Truncated
   Timestamp IE  for a Midpoint node. If the same IE is added in IOAM, what do
   you see as the benefit of using PT compared to IOAM?
   - In the draft you describe how to use PT to collect timestamps along a
   path. T64 is recorded in PTP 64 bit-long format. What is the format used to
   record a Truncated Timestamp? Also, I couldn't find an explanation why PT
   uses only one timestamp format and, for example, does not allow using NTP
   64 bit-long timestamp format.
   - Furthermore, one-way delay measurement requires clock synchronization.
   OIj the draft you use two use cases for PT, intercontinental and DC, what
   should be the accuracy of the clock synchronization in the domain to ensure
   the PT produces useful measurement data?
   - As I understand the process of collecting truncated timestamps at a
   midpoint system, it records the value into the HbH IPv6 EH. You suggest
   that the time value is "the time at which the packet egress the router".
   But since a new value is written in the packet, should the checksum be
   re-calculated? And if that is the case, would that cause a variable delay
   that affects the accuracy of the measurement provided by the PT method?
   - Related to the above mentioned scenario, I find that IOAM has an
   advantage compared with the PT method as a process of generating telemetry
   data can be separated from transporting that telemetry information for
   processing. For example, using IOAM Direct Export or Hybrid Two-Step
   mechanisms. Such separation allows for more accurate measurements and also
   can be conducted out-of-band relative to the monitored data flow.

I greatly appreciate your kind consideration of my comments and questions
and looking forward to an interesting discussion.


On Wed, Mar 9, 2022 at 6:14 AM Ahmed Abdelsalam (ahabdels) <ahabdels=> wrote:

> We have submitted a new I-D for Path Tracing in SRv6 networks (
> We are looking for your feedback and comments.
> 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 to facilitate operation of SR networks.
> Path Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-by-Hop
> extension header.
> We will present Path Tracing to the SPRING WG at next IETF (
> Thanks,
> Ahmed
> *From: * <>
> *Date: *Friday, 4 March 2022 at 16:48
> *To: *Ahmed Abdelsalam (ahabdels) <>, cf(mailer list) <
>>, Mark Yufit <>, Pablo Camarillo
> (pcamaril) <>, Pablo Camarillo (pcamaril) <
>>, Satoru Matsushima <>,
> Thomas.Graf <>, Yuanchao Su <
> *Subject: *New Version Notification for
> draft-filsfils-spring-path-tracing-00.txt
> A new version of I-D, draft-filsfils-spring-path-tracing-00.txt
> has been successfully submitted by Pablo Camarillo Garvia and posted to the
> IETF repository.
> Name:           draft-filsfils-spring-path-tracing
> Revision:       00
> Title:          Path Tracing in SRv6 networks
> Document date:  2022-03-04
> Group:          Individual Submission
> Pages:          15
> URL:
> Status:
> Htmlized:
> 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
> _______________________________________________
> ippm mailing list