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 <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)
<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
_______________________________________________
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
