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

From: "Ahmed Abdelsalam (ahabdels)" <[email-masked]>
Date: Wed, 9 Mar 2022 14:13:06 +0000

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: [email-masked] <[email-masked]>
Date: Friday, 4 March 2022 at 16:48
To: Ahmed Abdelsalam (ahabdels) <[email-masked]>, cf(mailer list) <[email-masked]>, Mark Yufit <[email-masked]>, Pablo Camarillo (pcamaril) <[email-masked]>, Pablo Camarillo (pcamaril) <[email-masked]>, Satoru Matsushima <[email-masked]>, Thomas.Graf <[email-masked]>, Yuanchao Su <[email-masked]>
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

---

From: Andrew Alston - IETF <[email-masked]>
Date: Mon, 14 Mar 2022 15:08:02 +0000

Hi There,

Speaking entirely as a working group participant,

I have two substantial concerns with this document at first skim read.

Firstly - the 12 bits for an interface ID - I have serious concerns that this will be far from sufficient.  Keep in mind you have interface specific VLAN's (that alone can eat 12 bits), you have PWHE terminated interfaces - and I know of several cases where those are used for termination of logical circuits that would be doing this type of traffic, etc etc, and in effect, you can very easily exceed the 4096 interface ID's on a single router.

Secondly, in the security considerations section of the document, last paragraph of section 11.  It states "The HBH-PT option MUST be processed at line rate." I think the wording here probably needs work.  Could we not say that "A router that cannot process the HBH-PT option in fast path must ignore said option" Because "line rate" does not actually refer to packets that avoid punt to the CPU - all it means is that the CPU's are fast enough to not slow other things down while processing it.

Thanks

Andrew

From: spring <[email-masked]> On Behalf Of Ahmed Abdelsalam (ahabdels)
Sent: Wednesday, March 9, 2022 5:13 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [spring] FW: New Version Notification for draft-filsfils-spring-path-tracing-00.txt

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<https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing>) to SPRING WG.

We will present Path Tracing to the SPRING WG at next IETF (https://datatracker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt<https://datatracker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt>)

Thanks,
Ahmed

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<https://www.ietf.org/archive/id/draft-filsfils-spring-path-tracing-00.txt>
Status:         https://datatracker.ietf.org/doc/draft-filsfils-spring-path-tracing/<https://datatracker.ietf.org/doc/draft-filsfils-spring-path-tracing/>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing<https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing>

Abstract:

The IETF Secretariat

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 14 Mar 2022 18:25:01 -0700

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=
[email-masked]> 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.
>
>
>
> 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.
>
>
>
> 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: [email-masked] <[email-masked]>
> *Date: *Friday, 4 March 2022 at 16:48
> *To: *Ahmed Abdelsalam (ahabdels) <[email-masked]>, cf(mailer list) <
> [email-masked]>, Mark Yufit <[email-masked]>, Pablo Camarillo
> (pcamaril) <[email-masked]>, Pablo Camarillo (pcamaril) <
> [email-masked]>, Satoru Matsushima <[email-masked]>,
> Thomas.Graf <[email-masked]>, Yuanchao Su <
> [email-masked]>
> *Subject: *New Version Notification for
> draft-filsfils-spring-path-tracing-00.txt
>
>
> 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:
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 15 Mar 2022 12:27:15 +0200

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.

---

From: "Ahmed Abdelsalam (ahabdels)" <[email-masked]>
Date: Tue, 22 Mar 2022 10:13:16 +0000

Hi Tal.

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

From: Tal Mizrahi <[email-masked]>
Date: Tuesday, 15 March 2022 at 11:28
To: Ahmed Abdelsalam (ahabdels) <ahabdels=[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [ippm] FW: New Version Notification for draft-filsfils-spring-path-tracing-00.txt
Dear authors,

A few comments:

[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.

[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).

[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.

[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.

---

From: "Ahmed Abdelsalam (ahabdels)" <[email-masked]>
Date: Tue, 22 Mar 2022 10:13:17 +0000

Hi Andrew,

From: ippm <[email-masked]> on behalf of Andrew Alston - IETF <andrew-ietf=[email-masked]>
Date: Monday, 14 March 2022 at 16:08
To: Ahmed Abdelsalam (ahabdels) <ahabdels=[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [ippm] New Version Notification for draft-filsfils-spring-path-tracing-00.txt
Hi There,

Firstly – the 12 bits for an interface ID – I have serious concerns that this will be far from sufficient.  Keep in mind you have interface specific VLAN’s (that alone can eat 12 bits), you have PWHE terminated interfaces – and I know of several cases where those are used for termination of logical circuits that would be doing this type of traffic, etc etc, and in effect, you can very easily exceed the 4096 interface ID’s on a single router.

[AA] As mentioned in the draft. The interface ID is assigned by an operator. It does not have to be either globally unique across the entire network, or even unique withing the node as long as the end-to-end path can be deterministically inferred based on the chain of Interface IDs.

Secondly, in the security considerations section of the document, last paragraph of section 11.  It states “The HBH-PT option MUST be processed at line rate.” I think the wording here probably needs work.  Could we not say that “A router that cannot process the HBH-PT option in fast path must ignore said option” Because “line rate” does not actually refer to packets that avoid punt to the CPU – all it means is that the CPU’s are fast enough to not slow other things down while processing it.

[AA] The intent is to avoid any slowdown in forwarding. draft-ietf-6man-hbh-processing uses slow-path and fast-path language and may provide better language to describe the requirement for HBH-PT option.  We’ll update that in the next version.

Thanks!

Thanks
Andrew

Dear SPRING WG,  IPPM WG,

Thanks,
Ahmed

Abstract:

The IETF Secretariat

---

From: "Ahmed Abdelsalam (ahabdels)" <[email-masked]>
Date: Tue, 22 Mar 2022 10:13:19 +0000

Hi Greg,

From: Greg Mirsky <[email-masked]>
Date: Tuesday, 15 March 2022 at 02:25
To: Ahmed Abdelsalam (ahabdels) <ahabdels=[email-masked]>, [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> wrote:
Dear SPRING WG,  IPPM WG,

Thanks,
Ahmed

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Date: Friday, 4 March 2022 at 16:48
To: Ahmed Abdelsalam (ahabdels) <[email-masked]<mailto:[email-masked]>>, cf(mailer list) <[email-masked]<mailto:[email-masked]>>, Mark Yufit <[email-masked]<mailto:[email-masked]>>, Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>, Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>, Satoru Matsushima <[email-masked]<mailto:[email-masked]>>, Thomas.Graf <[email-masked]<mailto:[email-masked]>>, Yuanchao Su <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-filsfils-spring-path-tracing-00.txt

Abstract:

The IETF Secretariat
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm