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

["Ahmed Abdelsalam (ahabdels)" <[e-mail]>]

Hi Greg,

Thanks for the review and comments. Please find Inline [AA]

From: Greg Mirsky <[e-mail]>
Date: Tuesday, 15 March 2022 at 02:25
To: Ahmed Abdelsalam (ahabdels) <ahabdels=[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [ippm] FW: New Version Notification for draft-filsfils-spring-path-tracing-00.txt
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.
[AA] While the examples and pseudocode in this draft focuses on the Active Measurement case, the HbH option can be used indifferently both in probe packets and data packets. For the PT midpoint view, it does not make any difference if HbH-PT is part of probe packet or 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?
[AA] PT and iOAM are tackling the problem from different angles, and as such their architecture differ.

  *   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.
[AA] Path Tracing can work indifferently with PTP 64-bit and NTP 64-bit. The Truncated Timestamp (TTS) is 8-bits selected from the 64-bit timestamp of the node. The position of selected 8-bits is identified by the TTS Template.

  *   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?
[AA] PT does not introduce any requirement in terms of clock synchronization accuracy, hence this is out of the scope of this draft.

  *   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?
[AA] Could you please clarify which checksum are you referring to?

  *   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.
[AA] The postcard and passport modes are two different ways of collecting packet path information from the network. The Path Tracing solution defined in this draft uses the passport mode. The original challenge of the passport mode is collecting the data from NPU, in the normal packet pipeline, at linerate. This challenge has been solved in Path tracing.
Thanks!
I greatly appreciate your kind consideration of my comments and questions and looking forward to an interesting discussion.

Regards,
Greg

On Wed, Mar 9, 2022 at 6:14 AM Ahmed Abdelsalam (ahabdels) <ahabdels=[e-mail]<mailto:[e-mail]>> wrote:
Dear SPRING WG,  IPPM WG,

We have submitted a new I-D for Path Tracing in SRv6 networks (https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing) to SPRING WG.

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 (https://datatracker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt)

Thanks,
Ahmed

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Friday, 4 March 2022 at 16:48
To: Ahmed Abdelsalam (ahabdels) <[e-mail]<mailto:[e-mail]>>, cf(mailer list) <[e-mail]<mailto:[e-mail]>>, Mark Yufit <[e-mail]<mailto:[e-mail]>>, Pablo Camarillo (pcamaril) <[e-mail]<mailto:[e-mail]>>, Pablo Camarillo (pcamaril) <[e-mail]<mailto:[e-mail]>>, Satoru Matsushima <[e-mail]<mailto:[e-mail]>>, Thomas.Graf <[e-mail]<mailto:[e-mail]>>, Yuanchao Su <[e-mail]<mailto:[e-mail]>>
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:            https://www.ietf.org/archive/id/draft-filsfils-spring-path-tracing-00.txt
Status:         https://datatracker.ietf.org/doc/draft-filsfils-spring-path-tracing/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing


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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ippm