Hi Tal, Thanks for the feedback.
We moved the draft to the IPPM WG based on the interest we have seen from the IPPM WG during IETF 118. https://datatracker.ietf.org/doc/draft-filsfils-ippm-path-tracing/00/ I agree it could be made generic to the IPv6 data plane. Today we have a small dependency on SRv6, but based on WG feedback we can change this once it's adopted. Thanks, Ahmed From: Tal Mizrahi <tal.mizrahi....@gmail.com> Date: Tuesday, 7 November 2023 at 14:13 To: draft-filsfils-spring-path-trac...@ietf.org <draft-filsfils-spring-path-trac...@ietf.org>, Ahmed Abdelsalam (ahabdels) <ahabd...@cisco.com>, IETF IPPM WG <i...@ietf.org>, SPRING WG List <spring@ietf.org> Subject: Question regarding draft-filsfils-spring-path-tracing Dear authors, A couple of questions: 1. Why not decouple the IPv6 path tracing option from SRv6? It does not seem to be strictly SRv6 related. You could potentially define the relevant SRv6 endpoint behavior in a separate draft. 2. Would it be possible to use the ICMPv6 Loopback message with an SRH and the path tracing option? That would mean that the ICMPv6 Loopback reply includes the original SRH of the Loopback message, and also the path tracing information of the original Loopback message. In this context "ICMPv6 Loopback" is as defined in https://datatracker.ietf.org/doc/draft-mcb-intarea-icmpv6-loopback/ Cheers, Tal.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
