Hi Mustapha, These are very good comments, many thanks. Let’ me check the details of the referred thread and come back to You next week.
Thanks & Cheers Bala’zs From: Mustapha Aissaoui (Nokia) <[email protected]> Sent: Wednesday, March 18, 2026 10:31 PM To: Balázs Varga A <[email protected]>; SPRING WG List <[email protected]>; IPv6 List <[email protected]> Subject: Re: New Version Notification for draft-varhal-6man-icmp-srv6-vpn-01.txt Hi Balazs, I have a couple of comments on this draft. The first one is to reference RFC 2473<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc2473*section-8__;Iw!!NEt6yMaO-gk!CQq_FdKjC1gmIXsGJG4jQ7N1Vqiian8wAqFRv79hihx0kcrkd9DMQMiDKTMEWmjTVjCAp5ToOHpDhefmyEnrsOAOGLTzd08$> as it is well described that an ICMP reply must be sent on the outer IPv6 header in the case of an IP-in-IP tunnel. For me this is the closest prior art we can refer to when discussing potential new solutions, other than ICMP tunneling. This RFC also describes a general ICMP relay function covering various ICMP error messages. In the specific context of a TCP/UDP traceroute probe, this relay function will only work for traceroute packets of routes in the global routing table as discussed in an earlier thread on draft-ali-6man-srv6-vpn-icmp-error-handling. It does however not address probes sent in VRF context. The second is regarding the use of a SRv6 service SID as the source address on the outer IPv6 header. The source address in the outer IPv6 header is used by downstream routers to report various ICMP error messages on the SRv6 tunnel, some of which are ad-hoc and triggered by malformed outer headers in user packets. Hence it cannot be sent to a specific VRF context of the ingress SRv6 PE. I can see a service SID being used as the source address of the traceroute for probes originating at the ingress SRv6 PE since the user can configure this specifically for these probes. But not for probes generated by the CE since they are treated as user packets at the ingress SRv6 PE and they would inherit the source address of the SRv6 tunnel. For probes originating at the ingress SRv6 PE, one can correlate the error message with a specific VPN or global routing table traceroute probe based on TCP or UDP port number. So there are alternatives too. Regards, Mustapha. From: Balázs Varga A <[email protected]<mailto:[email protected]>> Date: Monday, March 16, 2026 at 9:51 AM To: SPRING WG List <[email protected]<mailto:[email protected]>>, IPv6 List <[email protected]<mailto:[email protected]>> Subject: [spring] FW: New Version Notification for draft-varhal-6man-icmp-srv6-vpn-01.txt CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi, Based on the valuable feedbacks on the lists the draft on "ICMP Error Handling for VPNs in SRv6 Networks" was updated. Thanks & Cheers Bala'zs (and Joel) -----Original Message----- From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Monday, March 16, 2026 2:36 PM To: Balázs Varga A <[email protected]<mailto:[email protected]>>; Joel Halpern <[email protected]<mailto:[email protected]>> Subject: New Version Notification for draft-varhal-6man-icmp-srv6-vpn-01.txt A new version of Internet-Draft draft-varhal-6man-icmp-srv6-vpn-01.txt has been successfully submitted by Balazs Varga and posted to the IETF repository. Name: draft-varhal-6man-icmp-srv6-vpn Revision: 01 Title: ICMP Error Handling for VPNs in SRv6 Networks Date: 2026-03-16 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/archive/id/draft-varhal-6man-icmp-srv6-vpn-01.txt Status: https://datatracker.ietf.org/doc/draft-varhal-6man-icmp-srv6-vpn/ HTMLized: https://datatracker.ietf.org/doc/html/draft-varhal-6man-icmp-srv6-vpn Diff: https://author-tools.ietf.org/iddiff?url2=draft-varhal-6man-icmp-srv6-vpn-01 Abstract: This document specifies ICMP error handling in SRv6-based Virtual Private Networks, that support direct localization of failures. It provides a solution for connectivity check and fault localization without adding complexity to P nodes and keeps P nodes service agnostic. ICMP processing is changed only on ingress PE nodes and gains from adding VPN-specific information to the SRv6 encapsulated packet. Egress PE nodes are not involved in the forwarding of the ICMP error messages. Therefore, the solution provides visibility upto the failure even if ingress PE to egress PE connectivity is broken within the SR domain. The IETF Secretariat _______________________________________________ spring mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
