Hi Ahmed I agree that IPPM is a very good fit for path tracing work and falls in-line with the WG charter.
Kind Regards Gyan On Fri, Dec 1, 2023 at 11:52 AM Ahmed Abdelsalam (ahabdels) <ahabdels= 40cisco....@dmarc.ietf.org> wrote: > 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. > _______________________________________________ > 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
