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. Regards, Greg On Wed, Mar 9, 2022 at 6:14 AM Ahmed Abdelsalam (ahabdels) <ahabdels= 40cisco....@dmarc.ietf.org> 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: *internet-dra...@ietf.org <internet-dra...@ietf.org> > *Date: *Friday, 4 March 2022 at 16:48 > *To: *Ahmed Abdelsalam (ahabdels) <ahabd...@cisco.com>, cf(mailer list) < > c...@cisco.com>, Mark Yufit <mark.yu...@broadcom.com>, Pablo Camarillo > (pcamaril) <pcama...@cisco.com>, Pablo Camarillo (pcamaril) < > pcama...@cisco.com>, Satoru Matsushima <satoru.matsush...@g.softbank.co.jp>, > Thomas.Graf <thomas.g...@swisscom.com>, Yuanchao Su < > yitai....@alibaba-inc.com> > *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 > i...@ietf.org > https://www.ietf.org/mailman/listinfo/ippm >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
