Hi Bala’zs, see inline for some follow-up.
Regards, Mustapha. From: Balázs Varga A <[email protected]> Date: Friday, April 10, 2026 at 7:30 AM To: Mustapha Aissaoui (Nokia) <[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 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 Mustapha, Many thanks for the very good and relevant comments. 1, Regarding RFC2473: Yes, the described general ICMP relay function is similar to the VPN-associated-ICMP-process-function of the draft. The major difference is the capability to process probes sent in VRF context. SRv6 VPN is basically a form of IPv6 tunneling and some of its aspects (like Binding-SID) are form of nested tunneling. Do You propose to describe the ICMP-process-function in the draft as an extension of the RFC2473 ICMP relay function? MA> I would say we ought to address the following three topics: 1. Mention that processing by the ingress SRv6 PE of the ICMP reply message to a sent UDP/TCP traceroute probe is inline with the relay function specified in RFC 2473. 2. Clarify the scope of the relay function for traceroute probes. * For traceroute probes originating at the ingress SRv6 PE, ingress SRv6 PE can process replies for traceroute probes to destination prefixes in both global routing table and a VRF. * For traceroute probes originating at a CE, it seems to me ingress SRv6 PE can only process replies for traceroute probes to destination prefixes in the global routing table. I am not sure you can configure a specific VRF service SID as the source address for the entire SRv6 tunnel. See my comment on the next point below. 3. For probes which originate on the ingress SRv6 PE, we want to avoid receiving two replies to the same traceroute packet. One possible way for addressing this would be to recommend in draft-ali-6man-srv6-vpn-icmp-error-handling that a transit SRv6 router should only send a single ICMP reply message to a given expired traceroute packet, either to: * the source address in the outer IPv6 header which may trigger the relay function at the ingress SRv6 PE, or * to the original source address in the inner traceroute payload using the ICMP tunneling method. 2, Regarding SRv6 service SID as the source address: Yes, agree with your view, that for probes sent from ingress SRv6 PE using a service SID as source address is not the only solution. As the ingress SRv6 PE node is the originator of the packet more information/state exists on the node. Also, thanks for pointing out that downstream routers may report various ICMP error messages on the SRv6 tunnel, which may not be relevant for VRF endpoints. In my view, local termination or selective forwarding of ICMP error messages towards VRF endpoints is a decision of the VPN-associated-ICMP-process-function. Do You propose here to work on the details of such a selective filtering, similar to the description in RFC2473? MA> Yes, we need to add some details of the ICMP error message processing by the ingress SRv6 PE. I know some implementations use an incrementing source or dest UDP/TCP port number for the probes when incrementing the TTL/Hop-Limit of the traceroute packets. So for probes originated at the ingress SRv6 PE there is definitely an alternative to identify by the ingress SRv6 PE a specific traceroute session, be it in the global routing table or in a VRF, without setting the source address of the outer IPv6 header to a VRF service SID. For probes originated on a CE, it may be a tough sell to mandate that the source address of the SRv6 tunnel used by each VRF needs to be set to the VRF service SID. I understand your point that the ingress SRv6 PE can implement a selective forwarding of the SRv6 probes to a VRF but the truth is that the SRv6 tunnel leaves in the global routing table and it must be able to process any ICMP message, not just ICMP replies to a traceroute, from the SRv6 network without having any VRF service associated with it. Again, many thanks for your thoughtful comments. Cheers Bala’zs From: Mustapha Aissaoui (Nokia) <[email protected]<mailto:[email protected]>> Sent: Wednesday, March 18, 2026 10:31 PM To: Balázs Varga A <[email protected]<mailto:[email protected]>>; SPRING WG List <[email protected]<mailto:[email protected]>>; IPv6 List <[email protected]<mailto:[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]
