Hi Krzysztof, many thanks for your effort to verify the applicability of draft-varhal-6man-icmp-srv6-vpn. Please, note that it is the first version (v00), so further details will be added in upcoming versions, based on the valuable inputs from the mailing list discussions.
I think we need to apply same objective judgment rules for the proposed solutions. I will start a separate mail thread to clarify the expectations on VPN ping/trace in SRv6 networks. It is always good to agree on WHAT we intend to solve. :--)) You may explain more about "similar solution was initially as well discussed among authors of draft-ali" on the list. That would help a better understanding by the WG. Reactions to the technical comments done below. Regarding IPv4 handling: Yes, it needs further text. Your assumption and judgement on how it is provided by draft-varhal is not correct. The solution is based on RFC7600 (btw, similar to the method described in draft-ali). Anyway, point taken, a detailed description is needed in the next version. Regarding Hub-and-Spoke VPN: Yes, it needs a specific configuration. The structure of the used VRFs (i.e., vrf-in, vrf-out) determine routing and reachability of prefixes within the VPN. Connected nodes are reachable via vrf-in, SID(s) is announced for remote PE nodes from vrf-in. No SID allocation is needed for vrf-out. Draft-varhal states that a VPN-specific-SID is used as srcIP. Here, the VPN-specific-SID is the SID allocated for vrf-in, so the ICMP error message arrives to vrf-in and is NOT backholed. This scenario is natively resolved. ;--)) Regarding SRv6 policy (+ VPN): I strongly disagree with your view, you are you conflating things here and making invalid assumptions on draft-varhal. The encapsulation process on the headend node needs several input information to construct the outer header. One group of information is derived from the SR policy. The SR policy defines the path to which a node steers a packet flow. Applying a SR policy means to select the path (defined by a SID list) and placing the path descriptors into the dstIP and SRH fields of the tunnel encapsulation. Another group of information are needed as well, like srcIP, Traffic Class, FlowLabel, HopLimit, NextHeader. They are derived by other local functionalities. The srcIP MUST resolve to a unique node in the SR domain [RFC9256], what is fulfilled by draft-varhal. The srcIP is specific to the 'Headend'. Regarding Multi-level-encapsulation: Again this is v00. First, let's discuss the expected behavior. Draft-ali refers only to TI-LFA without any illustration (which is absolutely fine by me in the current discussion phase). TI-LFA is covered by draft-varhal as well. The more transport outer IPv6 headers preceding the customer's inner IPv6 header, the more sophisticated inspection is needed on the invoking packet ... Regarding MPLS/SRv6 scenarios: Again this is v00. First, let's discuss the expected behavior. Cheers Bala'zs From: Krzysztof Szarkowicz <[email protected]> Sent: Wednesday, March 4, 2026 10:29 AM To: Joel Halpern <[email protected]> Cc: Balázs Varga A <[email protected]>; IPv6 List <[email protected]> Subject: Re: [IPv6]Re: New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt Joel, Of course, in case of network failures (or configuration mistakes ?) causing no reachability to the egress or ingress, it will affect traceroute operation. In case when on 'P' node reachability to egress fails, it affects solution described in draft-ali-6man-srv6-vpn-icmp-error-handling. In case when on 'P' node reachability to ingress fails, it affects solution described in draft-varhal-6man-icmp-srv6-vpn. There are no miracles here, in fact. Best regards, Krzysztof On 2026 Mar 2, at 19:13, Joel Halpern <[email protected]<mailto:[email protected]>> wrote: Do you consider it to be a feature or a drawback of the MPLS solution that if the path to the egress fails, no responses to any traceroutes will be generated back to the source? I understand it is necessary in the MPLS case. From where I sit, it is a drawback. And one we can address in the SRv6 case. Yours, Joel On 3/2/2026 12:54 PM, Krzysztof Szarkowicz wrote: Hi Balázs, Thank you for your response. Appreciated. Please see inline my comments. Cheers, Krzysztof On 2026 Feb 27, at 17:22, Balázs Varga A <[email protected]><mailto:[email protected]> wrote: Hi Krzysztof, the purpose of the draft is to provide a solution to ICMP Error Handling for VPNs in SRv6 Networks without the shortcomings of MPLS like approaches. [Krzysztof] That is interesting, that we came to different conclusions, regarding shortcomings of the solution :-). Furthermore, it proposes new functionality only on the PE nodes. No P nodes are affected. P nodes can be standard compliant IPv6-only nodes. No change of the widely implemented ICMPv6 processing (RFC4443) is needed on them. [Krzysztof] Authors of the competitive solution (draft-ali-6man-srv6-vpn-icmp-error-handling) propose only change on P nodes (no change on PE nodes). In typical network, there is more PE nodes than P nodes. In any case, changes to the current behavior are needed (either on P or on PE). And, that is the reason for creating new standards. But, it doesn't really matter here, actually. More important are shortcomings of one versus another solution. One of the shortcomings of the solution described in draft-varhal-6man-icmp-srv6-vpn-00 is the IPv4 handling. Draft draft-varhal-6man-icmp-srv6-vpn describes only enigmatic "In case of an IPv4-VPN service, a translation of involved IP addresses is needed (between the related IPv6 and IPv4 addresses).", without giving more details, what does it mean. So, if P node has a valid IPv4 address (i.e. network with dual-stack during, for example, transition/migration period) IPv4 information of P node is lost in ICMP response, and the invoking node gets only some 'IPv6-to-IPv4 translated address', instead of real IPv4 address of P node. Similarly, if P node has only IPv6 address, again the invoking node gets only some 'IPv6-to-IPv4 translated address', instead of real IPv6 address of P node (that could be displayed, for example, in the traceroute output on the invoking node). Both of these shortcomings are resolved in the competitive draft. As stated in Section 3.2 of the draft: 2. PE1 encapsulates the packet in an SRv6 tunnel (Uniform model used). The srcIP of the encapsulation is a VPN specific SID of PE1. The solution works for any VPN setup including hub-and-spoke L3VPN. ICMP error generated for packets sent by PE1 (i.e., originated from PE1 hosts) are sent to PE1 and PE1 can send it to connected hosts. As only PE1 and P2 nodes are involved it works for any VPN topologies. [Krzysztof] In case of hub-and-spoke topologies, where the requirement is that CE-to-CE communications must happen through the hub (for example, for CE-to-CE security screening at some central location), on spoke PE there are typically at least two VRFs: let's call them VRF-in and VRF-out. Multiple CEs are connected to VRF-in, whereas VRF-out has no local connections. However, to prevent direct CE-to-CE communications (traffic between CEs should traverse the hub site - i.e. for security screening), traffic arrived from CEs in VRF-in is forced to VRF-out, and routed based on the routing table in VRF-out (which has in principle only default route to VRF-hub on some remote PE - not even connected routes). That is quite typical implementation of hub-and-spoke with direct CE-to-CE traffic prevention. Now, when ICMP error message arrives to VRF-out (based on principles described in draft-varhal-6man-icmp-srv6-vpn-00), it has only default route pointing to VRF-hub on remote PE (no connected routes). This ICMP Error Message will be blackholed, IMHO. Or, authors of draft-varhal-6man-icmp-srv6-vpn plan to describe in details, how to handle such hub-and-spoke scenario? This shortcoming is as well natively resolved in the competitive proposal. Similarly, the solution is transparent to the SRv6 policies used in a given network scenario. If someone is using SR policies for VPN traffic on e.g., PE1, the structure of SR policy in RFC 9256 (Section 2.13) still applies. The Headend node is still PE1, why should it be VPN specific? For example Section 8.4 of RFC 9256 clearly defines the usage of the SR policy information model. Segment list of the SR Policy is pushed to the encapsulated packet (e.g., in the SRH). RFC9256 does not states, that the PE should use is the headend from the SR policy as a srcIP. So, no need to create 2k SRv6 policies per remote PE (Endpoint), with exactly the same content. The 'Headend' refers to PE1 not the VPN. [Krzysztof] Virtually all SRv6 policy implementations I am aware of, implements SRv6 policy as some sort of IP tunnel, with source address of this tunnel equal to 'Headend' (typically: loopback) from SRv6 policy definition. My understanding is, that authors of draft-ali-6man-srv6-vpn-icmp-error-handling promote disconnection between 'Headend' defined on SRv6 policy, and encapsulation of that SRv6 policy (specifically: source IP address will differ from 'Headend'). The competitive proposal doesn't have this shortcoming, and keeps the consistent association between SRv6 policy 'headend' and the encapsulation (source IP is equal to 'headend'). Further shortcomings with draft-varhal-6man-icmp-srv6-vpn, as I see, are multi-domain designs, with multi-level encapsulations - multi-level tunnels (i.e. B-SID mentioned earlier in one of the comments). Node performing additional encapsulation doesn't necessarily have any VRFs at all, and pushes some additional (tunnel) headers, using as source IP address some local P address (typically - loopback). draft-varhal-6man-icmp-srv6-vpn doesn't describe, how to handle such scenarios. Competitive draft handles such scenarios natively. Also, I don't see in the draft any discussion regarding mixed MPLS/SRv6 scenarios (i.e. during migration), where either MPLS is tunneled over SRv6 (Mo6), or the opposite (6oM), or some sort of encapsulation conversion between MPLS and SRv6 is done (draft-ietf-spring-srv6-mpls-interworking). While competitive draft handles these scenarios natively, I am not sure, how such scenarios will be handled using the principles described in draft-varhal-6man-icmp-srv6-vpn. The above shortcomings of the solution described in draft-varhal-6man-icmp-srv6-vpn, while similar solution was initially as well discussed among authors of draft-ali-6man-srv6-vpn-icmp-error-handling, resulted in the solution documented in draft-ali-6man-srv6-vpn-icmp-error-handling, which doesn't have shortcomings mentioned above. Cheers Bala'zs From: Krzysztof Szarkowicz <[email protected]><mailto:[email protected]> Sent: Thursday, February 26, 2026 7:07 PM To: Balázs Varga A <[email protected]><mailto:[email protected]> Cc: IPv6 List <[email protected]><mailto:[email protected]>; Mr. Zafar Ali <[email protected]><mailto:[email protected]> Subject: Re: [IPv6]New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt Hi Balázs, Further question: how it will work with SRv6 policies? RFC 9256 (Section 2.13)specifies SR policy as follows: SR Policy POL1 <Headend = H1, Color = 1, Endpoint = E1> Candidate Path CP1 <Protocol-Origin = 20, Originator = 64511:192.0.2.1, Discriminator = 1> Preference 200 Priority 10 Segment List 1 <SID11...SID1i>, Weight W1 Segment List 2 <SID21...SID2j>, Weight W2 Candidate Path CP2 <Protocol-Origin = 20, Originator = 64511:192.0.2.2, Discriminator = 2> Preference 100 Priority 10 Segment List 3 <SID31...SID3i>, Weight W3 Segment List 4 <SID41...SID4j>, Weight W4 So, having for example 2k VPNs, will we need to create 2k SRv6 policies per remote PE (Endpoint), with exactly the same content, except 'Headend'? As, I assume, in the 'Headend', we will need to encode 'VPN specific SID'? And, each time some VPN is added/removed, SRv6 Policy needs to be added/removed? Cheers, Krzysztof On 2026 Feb 26, at 12:35, Krzysztof Szarkowicz <[email protected]<mailto:[email protected]>> wrote: Hi Balázs. 'VPN specific SID' is not present in the srcIP of the invoking SRv6 packet. srcIP of the invoking SRv6 packet is typically loopback (or local locator), and the same srcIP is used for transporting traffic of all VPNs on given PE node. Or, the purpose of the draft, is to mandate that different source is used per VPN (current SRv6 implementations don't do that). How your draft will handle hub-and-spoke L3VPN deployments, where PE1 hosts spoke VRF, and - apart from locally connected routes - the only route in that VRF is default route pointing to hub VRF (which resides on PE2)? Cheers, Krzysztof On 2026 Feb 26, at 12:04, Balázs Varga A <[email protected]<mailto:[email protected]>> wrote: Hi Krzysztof, Thanks for the note. Yes, we are aware of the MPLS approach like draft. With our proposal we intend to get rid of the shortcomings of an MPLS like solution. Regarding your question: At P2 the 'VPN specific SID' is present in the srcIP of the invoking SRv6 packet. P2 is not service aware. P2 just does RFC4443 by copying the srcIP of the invoking packet to the dstIP of the generated ICMP error message. No extra functionality is needed on the P2 node. Thanks & Cheers Bala'zs From: Krzysztof Szarkowicz <[email protected]<mailto:[email protected]>> Sent: Thursday, February 26, 2026 9:56 AM To: Balázs Varga A <[email protected]<mailto:[email protected]>> Cc: IPv6 List <[email protected]<mailto:[email protected]>>; Mr. Zafar Ali <[email protected]<mailto:[email protected]>> Subject: Re: [IPv6]New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt Ritkán kap e-mailt a(z) [email protected]<mailto:[email protected]> e-mail-címről. Tudja meg, miért fontos ez<https://aka.ms/LearnAboutSenderIdentification> Hi Balázs, Please note, there is another draft on this topic already: https://datatracker.ietf.org/doc/draft-ali-6man-srv6-vpn-icmp-error-handling/ Regarding your draft, 4th step of the procedure: >> P2 generates an ICMP Error Message and sends it to PE1, using the VPN >> specific SID as a dstIP. How P2 know the 'VPN specific SID'? Cheers, Krzysztof On 2026 Feb 25, at 09:17, Balázs Varga A <[email protected]<mailto:[email protected]>> wrote: Hi, We have uploaded a new draft on "ICMP Error Handling for VPNs in SRv6 Networks". The draft proposes a solution that provides a native IPv6 method what does NOT have the drawbacks inherited by methods based on the MPLS based VPN ping or traceroute concept. It solves the problem that P nodes are not VPN aware without sending the ICMP error message to the egress PE router for a VPN lookup. It makes P nodes service agnostic and allows building IPv6-only core networks. Comments and suggestions are welcome. Thanks & Cheers Bala'zs -----Original Message----- From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Wednesday, February 25, 2026 8:07 AM 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-00.txt A new version of Internet-Draft draft-varhal-6man-icmp-srv6-vpn-00.txt has been successfully submitted by Balazs Varga and posted to the IETF repository. Name: draft-varhal-6man-icmp-srv6-vpn Revision: 00 Title: ICMP Error Handling for VPNs in SRv6 Networks Date: 2026-02-24 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-varhal-6man-icmp-srv6-vpn-00.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 Abstract: This document specifies ICMP error handling in SRv6-based Virtual Private Networks. The IETF Secretariat -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected]<mailto:[email protected]> List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/ -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected]<mailto:[email protected]> List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/ --------------------------------------------------------------------
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
