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

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

Hi Tal.

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

From: Tal Mizrahi <[e-mail]>
Date: Tuesday, 15 March 2022 at 11:28
To: Ahmed Abdelsalam (ahabdels) <ahabdels=[e-mail]>, [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
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)
<ahabdels=[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] <[e-mail]>
> Date: Friday, 4 March 2022 at 16:48
> To: Ahmed Abdelsalam (ahabdels) <[e-mail]>, cf(mailer list) <[e-mail]>, Mark Yufit <[e-mail]>, Pablo Camarillo (pcamaril) <[e-mail]>, Pablo Camarillo (pcamaril) <[e-mail]>, Satoru Matsushima <[e-mail]>, Thomas.Graf <[e-mail]>, Yuanchao Su <[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]
> https://www.ietf.org/mailman/listinfo/ippm