Hi Balázs,
OK, I will wait for next revision of the draft, with more details on the issues I raised. Just one comment inline. Cheers, Krzysztof > On 2026 Mar 4, at 15:38, Balázs Varga A <[email protected]> wrote: > > 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. ;--)) [Krzysztof] I am not sure, how it is solved. Assume you have 1000 VRFs on the PE-1, and packet is routed on PE-1 inside VRF-123 towards remote PE-2. This VRF-123 on PE-1 has only default route (pointing to remote PE-2). What SID should be used in the srcIP for such packet? > > 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]
