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

[Pablo Camarillo (pcamaril)]

Hi Ruediger,

Many thanks for your email. Glad you appreciate the PT proposal for SRv6 
networks.
We have experimental implementation at linerate in Broadcom Jericho 2, Cisco 
Silicon One, Marvell Prestera, and Cisco ASR9k (as well of opensource 
software). It would be great to hear from other vendors whether they can 
process this at linerate as well.

With regards to the SR-MPLS draft, we are finalizing the text and we will post 
it soon for feedback.
With regards to the time-synchronization considerations, many thanks on your 
feedback. We agree with you, and we'll add more considerations in the next 
revision.

Thanks,
Pablo.

-Original Message-
From: ruediger.g...@telekom.de  
Sent: viernes, 1 de abril de 2022 11:12
To: ahabdels=40cisco@dmarc.ietf.org
Cc: spring@ietf.org; i...@ietf.org; draft-filsfils-spring-path-trac...@ietf.org
Subject: [ippm] FW: New Version Notification for 
draft-filsfils-spring-path-tracing-00.txt

Hi Ahmed,

Thanks for the draft. I appreciate the small and well specified format of the 
measurement and hope that endpoints and transit routers supporting Path Tracing 
in SRv6 networks are able to fill in the specified fields at linerate during 
forwarding. I'd also appreciate an SR-MPLS version of the draft.

I'd suggest to add more text related to the following statement:

 Note: all routers across the network MUST have time-
 synchronization.  The mechanism used for time synchronization
 is out of the scope of this draft.

An operator should be able to qualify an applicable time-synchronisation by 
guidance of the draft. If Truncated Timestamp configuration depends on the 
precision of time synchronization, guidance for interested operators should be 
part of the draft. The choice of timestamp resolution may further depend on 
locally configured buffers. A Truncated Timestamp working well in the absence 
of congestion, but creating erroneous information with the onset of congestion 
might not be desired. Maybe a discussion on wrapping / overflow may help too. 
Finally, the precision of the synchronization needs to be monitored. That may 
be done out of band, but  centralized processing should be aware of timestamps 
created by a router with (temporarily) bad synch. A temporal change in 
precision of or a  loss of synch are common networking synch-events.

While the mechanism used for time synchronization doesn't need to be defined in 
the draft, a reference to some applicable synchronization mechanisms would be 
helpful. The list doesn't have to be complete, please add some commodity 
examples.

Editorial nit: To me, a binding "Requirement" shouldn't be a "Note".

Regards,

Ruediger


On Wed, Mar 9, 2022 at 4:14 PM Ahmed Abdelsalam (ahabdels) 
 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 
> 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:
> 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
>

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

[Ahmed Abdelsalam (ahabdels)]

Hi Greg,

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

From: Greg Mirsky 
Date: Tuesday, 15 March 2022 at 02:25
To: Ahmed Abdelsalam (ahabdels) , 
draft-filsfils-spring-path-trac...@ietf.org 

Cc: spring@ietf.org , spring-cha...@ietf.org 
, i...@ietf.org 
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) 
mailto: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 
mailto:internet-dra...@ietf.org>>
Date: Friday, 4 March 2022 at 16:48
To: Ahmed Abdelsalam (ahabdels) 
mailto:ahabd...@cisco.com>>, cf(mailer list) 
mailto:c...@cisco.com>>, Mark Yufit 
mailto:mark.yu...@broadcom.com>>, Pablo Camarillo 
(pcamaril) m

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

[Ahmed Abdelsalam (ahabdels)]

Hi Tal.

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

From: Tal Mizrahi 
Date: Tuesday, 15 March 2022 at 11:28
To: Ahmed Abdelsalam (ahabdels) , 
spring@ietf.org , i...@ietf.org , 
draft-filsfils-spring-path-trac...@ietf.org 

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

Thanks for sharing this interesting draft.
Per-hop measurement and reporting is a very important OAM tool, and
there is quite a bit of ongoing / previously proposed work in the IETF
about this topic.

A few comments:
1. It looks like the draft defines two aspects:  (a) the path tracing
IPv6 option, which is not specific to segment routing, but is actually
applicable to IPv6 routers in general, and (b) an SRH TLV. It seems
like the SRH TLV could alternatively be defined as a generic IPv6
destination option. Is there anything that functionally limits this
feature to networks that use segment routing?

[AA] Path Tracing has been designed to work on segment routing networks. As 
such, it leverages a few SRv6 constructs: the binding SID (End.B6.TEF) at the 
sink node, some assumptions from SR networks that are particularly useful for 
security (i.e. the SR Domain) and others.

2. As Greg pointed out in a previous email, the functionality here
seems very similar to IOAM. The PT option could actually be
implemented by using an IOAM trace option: by defining a couple of new
data fields you could get an equally compact number of bits as the PT
option in the current draft.  The SRH TLV could alternatively be
defined as an IOAM Edge-to-edge option (again, maybe with a couple of
new data fields). Is there a reason why this is a new protocol, rather
than just defining new data field types in IOAM?

[AA] We believe that PT and iOAM are tackling the problem from different 
angles. We don’t believe that IOAM with trace option could address our case 
(particularly, we have ensured that PT can be implemented at linerate across 
most silicon).

3. Time synchronization is defined as a 'MUST' in the draft, but it
seems like you can benefit from path tracing even in cases where
synchronization is not possible. Have you considered such use cases?

[AA] I agree with you. For example, simply collecting the interface IDs is 
already valuable. However, it seems all the operators that would be interested 
in PT do have time synchronization in their network. Hence there seems to be no 
value on that. Any feedback is welcomed.


4. Regarding 'MCD.TTS (Truncated Timestamp)': rather than defining
some of the bits to represent milliseconds and other bits to represent
microseconds, it may be more hardware-friendly to define a subset of
the bits of timestamp formats that are commonly implemented in
hardware, such as the PTP timestamp format or the NTP timestamp
format.

[AA] We will clarify the text in the draft. What you are proposing is exactly 
how it works today. The TTS template defines the position of 8-bits to be 
selected from the node timestamp. The HW will just copy these bits into the 
HbH. Still, part of the selected bits can represent milliseconds and part can 
representing microseconds. For example, if the operator configures a template 
that selects bits 16 to 23, this means that 4 most significant bits are coming 
from the part carrying the milliseconds and the 4 least significant bits will 
be carrying fraction of millisecond (i.e., unit of microseconds)

Thanks!

Cheers,
Tal.

On Wed, Mar 9, 2022 at 4:14 PM Ahmed Abdelsalam (ahabdels)
 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 
> 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:  2

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

[Tal Mizrahi]

Dear authors,

Thanks for sharing this interesting draft.
Per-hop measurement and reporting is a very important OAM tool, and
there is quite a bit of ongoing / previously proposed work in the IETF
about this topic.

A few comments:
1. It looks like the draft defines two aspects:  (a) the path tracing
IPv6 option, which is not specific to segment routing, but is actually
applicable to IPv6 routers in general, and (b) an SRH TLV. It seems
like the SRH TLV could alternatively be defined as a generic IPv6
destination option. Is there anything that functionally limits this
feature to networks that use segment routing?
2. As Greg pointed out in a previous email, the functionality here
seems very similar to IOAM. The PT option could actually be
implemented by using an IOAM trace option: by defining a couple of new
data fields you could get an equally compact number of bits as the PT
option in the current draft.  The SRH TLV could alternatively be
defined as an IOAM Edge-to-edge option (again, maybe with a couple of
new data fields). Is there a reason why this is a new protocol, rather
than just defining new data field types in IOAM?
3. Time synchronization is defined as a 'MUST' in the draft, but it
seems like you can benefit from path tracing even in cases where
synchronization is not possible. Have you considered such use cases?
4. Regarding 'MCD.TTS (Truncated Timestamp)': rather than defining
some of the bits to represent milliseconds and other bits to represent
microseconds, it may be more hardware-friendly to define a subset of
the bits of timestamp formats that are commonly implemented in
hardware, such as the PTP timestamp format or the NTP timestamp
format.

Cheers,
Tal.

On Wed, Mar 9, 2022 at 4:14 PM Ahmed Abdelsalam (ahabdels)
 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 
> 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:
> 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

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

[Greg Mirsky]

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)  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 
> *Date: *Friday, 4 March 2022 at 16:48
> *To: *Ahmed Abdelsalam (ahabdels) , cf(mailer list) <
> c...@cisco.com>, Mark Yufit , Pablo Camarillo
> (pcamaril) , Pablo Camarillo (pcamaril) <
> pcama...@cisco.com>, Satoru Matsushima ,
> Thomas.Graf , 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.ie