Hi Krzysztof, many thanks for the review of the updated draft. Reaction as follows:
1, Multiple IP encapsulation (e.g., B-SID): I do not think this is an VPN-specific issue. It is a more general one. Let's assume such a network (B-SID used between P2/P3/P4): A--PE1--P1--P2==P3==P4--P5--PE2--B If You are tracerouting PE2 from PE1 and Your HL expire at P3, as per current RFCs, the ICMP error is sent to P2 and PE1 will not receive the ICMP error message. The multiple encapsulation part of the path is not visible for the traceroute. Note, that there are no VPNs in the above example. The issue is not VPN specific, but VPN traceroute also suffers from this unwanted characteristics. I think we agree that here we need a solution, but I would not expect from a VPN specific solution to solve it. We need a more general one. 2, Real IPv4 address of 'P' node: This is covered in the draft. Please, double check the last paragraph in section 3.4. It is also part of the illustration in Section 3.5 (see the last PE1_out packet at the end of the section). 3. Handling migration/interop (MPLS <-> SRv6) scenarios: Please clarify by describing the scenario details You are referring to. Many thanks. 4. Handling VPNs with DX4/DX6 SIDs: This is covered in the draft. Please, double check Section 3.2. The paragraph after the "Packet processing" steps clarifies it in detail. 5. Handling of Hub-and-Spoke VRFs: This is covered in the draft. Please, double check Section 3.2. The second paragraph after the "Packet processing" steps clarifies it in detail. 6. Routable VPN-specific SID + multi-domain scenario: Multi-domain has its side-effects. See reply regarding item 1). 7. Different visibility for served VPNs Yes, this section needs some further clarification. It is an additional (optional) capability of the VPN-associated-ICMP-process-function. We will update for the next version. Thanks & Cheers Bala'zs From: Krzysztof Szarkowicz <[email protected]> Sent: Monday, March 30, 2026 10:01 AM To: Balázs Varga A <[email protected]> Cc: SPRING WG List <[email protected]>; IPv6 List <[email protected]>; Mustapha Aissaoui (Nokia) <[email protected]> Subject: Re: [spring] New Version Notification for draft-varhal-6man-icmp-srv6-vpn-01.txt Hi Balázs, I have checked the updated version of the draft. It addresses some shortcomings of this solution raised for initial version of the draft, but is still doesn't address many other shortcomings: 1. Handling of multiple IP encapsulations (e.g. expanding of B-SID with encap mode) on the node that is not service aware - i.e., B-SID is expanded on a node without VRF, and with no service prefix visibility) 2. Providing real IPv4 address of 'P' node (when such address exists - for example during migration scenarios, when dual IPv4/IPv6 stack is used) to the node invoking IPv4 traceroute 3. Handling migration/interop (MPLS <-> SRv6) scenarios 4. Handling VPNs with DX4/DX6 SIDs, where DT4/DT6/DT46 SIDs are not deployed 5. Handling of Hub-and-Spoke VRFs, where on PE traffic incoming on PE-CE interfaces in multiple local VRFs, is forced (vendor terminology: filter based forwarding, policy based routing, etc.) via single outgoing VRF (VRF-out) 6. "As the locator part of the VPN-specific SID is routable within the SRv6 domain other PE and P nodes of the SRv6 domain can send/route packets to it." -> this is not necessarily true in multi-domain designs, with B-SID expansion at domain boundaries. 7. "It can hide the SIDs used inside the SRv6 domain and can provide different visibility for served VPNs if needed." -> Not sure, if I understand this statement Cheers, Krzysztof On 2026 Mar 18, at 22:30, Mustapha Aissaoui (Nokia) <[email protected]<mailto:[email protected]>> wrote: 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]<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]
