[spring] Re: [IPv6]Re: New draft: draft-varhal-6man- icmp-srv6-vpn-00.txt
Balázs Varga A <[email protected]> Wed, 4 Mar 2026 14:38:39 +0000
| Newsgroups | gmane.ietf.spring,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <AM0PR07MB593888E187A0D61A0A17BF24AC7CA@AM0PR07MB5938.eurprd07.prod.outlook.com> |
--===============6609350965226026240== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AM0PR07MB593888E187A0D61A0A17BF24AC7CAAM0PR07MB5938eurp_" --_000_AM0PR07MB593888E187A0D61A0A17BF24AC7CAAM0PR07MB5938eurp_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable 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=E1zs Varga A <[email protected]>; IPv6 List <[email protected]= g> 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 ?) causin= g no reachability to the egress or ingress, it will affect traceroute opera= tion. In case when on 'P' node reachability to egress fails, it affects sol= ution described in draft-ali-6man-srv6-vpn-icmp-error-handling. In case whe= n 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:jmh@joelh= alpern.com>> 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 ge= nerated 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 c= ase. Yours, Joel On 3/2/2026 12:54 PM, Krzysztof Szarkowicz wrote: Hi Bal=E1zs, Thank you for your response. Appreciated. Please see inline my comments. Cheers, Krzysztof On 2026 Feb 27, at 17:22, Bal=E1zs Varga A <[email protected]><ma= ilto:[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, reg= arding 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-ic= mp-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, chang= es 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 de= scribes only enigmatic "In case of an IPv4-VPN service, a translation of in= volved 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 val= id IPv4 address (i.e. network with dual-stack during, for example, transiti= on/migration period) IPv4 information of P node is lost in ICMP response, a= nd the invoking node gets only some 'IPv6-to-IPv4 translated address', inst= ead of real IPv4 address of P node. Similarly, if P node has only IPv6 addr= ess, again the invoking node gets only some 'IPv6-to-IPv4 translated addres= s', instead of real IPv6 address of P node (that could be displayed, for ex= ample, in the traceroute output on the invoking node). Both of these shortc= omings 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 t= hat CE-to-CE communications must happen through the hub (for example, for C= E-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. Howe= ver, 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 i= n VRF-out (which has in principle only default route to VRF-hub on some rem= ote PE - not even connected routes). That is quite typical implementation o= f hub-and-spoke with direct CE-to-CE traffic prevention. Now, when ICMP err= or message arrives to VRF-out (based on principles described in draft-varha= l-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, implem= ents SRv6 policy as some sort of IP tunnel, with source address of this tun= nel equal to 'Headend' (typically: loopback) from SRv6 policy definition. M= y understanding is, that authors of draft-ali-6man-srv6-vpn-icmp-error-hand= ling promote disconnection between 'Headend' defined on SRv6 policy, and en= capsulation of that SRv6 policy (specifically: source IP address will diffe= r from 'Headend'). The competitive proposal doesn't have this shortcoming, and keeps the consi= stent association between SRv6 policy 'headend' and the encapsulation (sour= ce IP is equal to 'headend'). Further shortcomings with draft-varhal-6man-icmp-srv6-vpn, as I see, are mu= lti-domain designs, with multi-level encapsulations - multi-level tunnels (= i.e. B-SID mentioned earlier in one of the comments). Node performing addit= ional encapsulation doesn't necessarily have any VRFs at all, and pushes so= me additional (tunnel) headers, using as source IP address some local P add= ress (typically - loopback). draft-varhal-6man-icmp-srv6-vpn doesn't descri= be, 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 sce= narios (i.e. during migration), where either MPLS is tunneled over SRv6 (Mo= 6), or the opposite (6oM), or some sort of encapsulation conversion between= MPLS and SRv6 is done (draft-ietf-spring-srv6-mpls-interworking). While co= mpetitive draft handles these scenarios natively, I am not sure, how such s= cenarios will be handled using the principles described in draft-varhal-6ma= n-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 auth= ors of draft-ali-6man-srv6-vpn-icmp-error-handling, resulted in the solutio= n 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:kszarkowicz@gmail= .com> Sent: Thursday, February 26, 2026 7:07 PM To: Bal=E1zs Varga A <[email protected]><mailto:balazs.a.varga@er= icsson.com> Cc: IPv6 List <[email protected]><mailto:[email protected]>; Mr. Zafar Ali <zali@ci= sco.com><mailto:[email protected]> Subject: Re: [IPv6]New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt Hi Bal=E1zs, Further question: how it will work with SRv6 policies? RFC 9256 (Section 2.= 13)specifies SR policy as follows: SR Policy POL1 <Headend =3D H1, Color =3D 1, Endpoint =3D E1> Candidate Path CP1 <Protocol-Origin =3D 20, Originator =3D 64511:192.0.2.1, Discriminator =3D = 1> Preference 200 Priority 10 Segment List 1 <SID11...SID1i>, Weight W1 Segment List 2 <SID21...SID2j>, Weight W2 Candidate Path CP2 <Protocol-Origin =3D 20, Originator =3D 64511:192.0.2.2, Discriminator =3D = 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/remove= d? Cheers, Krzysztof On 2026 Feb 26, at 12:35, Krzysztof Szarkowicz <[email protected]<mailt= o:[email protected]>> wrote: Hi Bal=E1zs. '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 p= er 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 t= hat VRF is default route pointing to hub VRF (which resides on PE2)? Cheers, Krzysztof On 2026 Feb 26, at 12:04, Bal=E1zs Varga A <[email protected]<mai= lto:[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:kszarkowicz@gmail.= com>> Sent: Thursday, February 26, 2026 9:56 AM To: Bal=E1zs Varga A <[email protected]<mailto:balazs.a.varga@eri= csson.com>> Cc: IPv6 List <[email protected]<mailto:[email protected]>>; Mr. Zafar Ali <zali@ci= sco.com<mailto:[email protected]>> Subject: Re: [IPv6]New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt Ritk=E1n kap e-mailt a(z) [email protected]<mailto:[email protected]= m> e-mail-c=EDmr=F5l. Tudja meg, mi=E9rt fontos ez<https://aka.ms/LearnAbou= tSenderIdentification> Hi Bal=E1zs, Please note, there is another draft on this topic already: https://datatrac= ker.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 sp= ecific SID as a dstIP. How P2 know the 'VPN specific SID'? Cheers, Krzysztof On 2026 Feb 25, at 09:17, Bal=E1zs Varga A <balazs.a.varga=3D40ericsson.com= @dmarc.ietf.org<mailto:[email protected]>> wro= te: Hi, We have uploaded a new draft on "ICMP Error Handling for VPNs in SRv6 Netwo= rks". 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 trac= eroute concept. It solves the problem that P nodes are not VPN aware without sending the IC= MP 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]> <internet-d= [email protected]<mailto:[email protected]>> Sent: Wednesday, February 25, 2026 8:07 AM To: Bal=E1zs Varga A <[email protected]<mailto:balazs.a.varga@eri= csson.com>>; Joel Halpern <[email protected]<mailto:joel.halpern@er= icsson.com>> Subject: New Version Notification for draft-varhal-6man-icmp-srv6-vpn-00.tx= t 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 reposito= ry. 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-0= 0.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]/ -------------------------------------------------------------------- --_000_AM0PR07MB593888E187A0D61A0A17BF24AC7CAAM0PR07MB5938eurp_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 2"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Helvetica; panose-1:2 11 6 4 2 2 2 2 2 4;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Aptos;} @font-face {font-family:"Segoe UI"; panose-1:2 11 5 2 4 2 4 2 2 3;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; font-size:12.0pt; font-family:"Aptos",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; font-size:10.0pt; font-family:"Courier New";} span.apple-converted-space {mso-style-name:apple-converted-space;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas;} span.EmailStyle23 {mso-style-type:personal-reply; font-family:"Aptos",sans-serif; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple" style=3D"word-wrap:brea= k-word"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Hi Krzysztof,<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">many thanks for your effort to verify the applicabil= ity of <o:p> </o:p></p> <p class=3D"MsoNormal"><span lang=3D"DE">draft-varhal-6man-icmp-srv6-vpn. <= /span>Please, note that it is <o:p></o:p></p> <p class=3D"MsoNormal">the first version (v00), so further details will be = added<o:p></o:p></p> <p class=3D"MsoNormal">in upcoming versions, based on the valuable inputs f= rom<o:p></o:p></p> <p class=3D"MsoNormal">the mailing list discussions.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">I think we need to apply same objective judgment rul= es for <o:p> </o:p></p> <p class=3D"MsoNormal">the proposed solutions. I will start a separate mail= thread<o:p></o:p></p> <p class=3D"MsoNormal">to clarify the expectations on VPN ping/trace in SRv= 6<o:p></o:p></p> <p class=3D"MsoNormal">networks. It is always good to agree on WHAT we inte= nd to <o:p> </o:p></p> <p class=3D"MsoNormal">solve. :--))<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">You may explain more about "similar solution wa= s initially <o:p> </o:p></p> <p class=3D"MsoNormal">as well discussed among authors of draft-ali" o= n the list.<o:p></o:p></p> <p class=3D"MsoNormal">That would help a better understanding by the WG.<o:= p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Reactions to the technical comments done below.<o:p>= </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Regarding IPv4 handling:<o:p></o:p></p> <p class=3D"MsoNormal">Yes, it needs further text. Your assumption and judg= ement<o:p></o:p></p> <p class=3D"MsoNormal">on how it is provided by draft-varhal is not correct= . The <o:p> </o:p></p> <p class=3D"MsoNormal">solution is based on RFC7600 (btw, similar to the me= thod <o:p> </o:p></p> <p class=3D"MsoNormal">described in draft-ali). Anyway, point taken, a deta= iled <o:p> </o:p></p> <p class=3D"MsoNormal">description is needed in the next version.<o:p></o:p= ></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Regarding Hub-and-Spoke VPN:<o:p></o:p></p> <p class=3D"MsoNormal">Yes, it needs a specific configuration. The structur= e of<o:p></o:p></p> <p class=3D"MsoNormal">the used VRFs (i.e., vrf-in, vrf-out) determine rout= ing<o:p></o:p></p> <p class=3D"MsoNormal">and reachability of prefixes within the VPN. Connect= ed <o:p> </o:p></p> <p class=3D"MsoNormal">nodes are reachable via vrf-in, SID(s) is announced = for <o:p> </o:p></p> <p class=3D"MsoNormal">remote PE nodes from vrf-in. No SID allocation is ne= eded<o:p></o:p></p> <p class=3D"MsoNormal">for vrf-out. Draft-varhal states that a VPN-specific= -SID <o:p> </o:p></p> <p class=3D"MsoNormal">is used as srcIP. Here, the VPN-specific-SID is the = SID<o:p></o:p></p> <p class=3D"MsoNormal">allocated for vrf-in, so the ICMP error message arri= ves <o:p> </o:p></p> <p class=3D"MsoNormal">to vrf-in and is NOT backholed. <o:p></o:p></p> <p class=3D"MsoNormal">This scenario is natively resolved. ;--))<o:p></o:p>= </p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Regarding SRv6 policy (+ VPN):<o:p></o:p></p> <p class=3D"MsoNormal">I strongly disagree with your view, you are you conf= lating<o:p></o:p></p> <p class=3D"MsoNormal">things here and making invalid assumptions on draft-= varhal. <o:p> </o:p></p> <p class=3D"MsoNormal">The encapsulation process on the headend node needs = <o:p></o:p></p> <p class=3D"MsoNormal">several input information to construct the outer hea= der. <o:p> </o:p></p> <p class=3D"MsoNormal">One group of information is derived from the SR poli= cy.<o:p></o:p></p> <p class=3D"MsoNormal">The SR policy defines the path to which a node steer= s a <o:p> </o:p></p> <p class=3D"MsoNormal">packet flow. Applying a SR policy means to select th= e path<o:p></o:p></p> <p class=3D"MsoNormal">(defined by a SID list) and placing the path descrip= tors <o:p> </o:p></p> <p class=3D"MsoNormal">into the dstIP and SRH fields of the tunnel encapsul= ation. <o:p> </o:p></p> <p class=3D"MsoNormal">Another group of information are needed as well, lik= e srcIP,<o:p></o:p></p> <p class=3D"MsoNormal">Traffic Class, FlowLabel, HopLimit, NextHeader. They= are<o:p></o:p></p> <p class=3D"MsoNormal">derived by other local functionalities. The srcIP MU= ST<o:p></o:p></p> <p class=3D"MsoNormal">resolve to a unique node in the SR domain [RFC9256],= <o:p></o:p></p> <p class=3D"MsoNormal">what is fulfilled by draft-varhal. The srcIP is spec= ific <o:p> </o:p></p> <p class=3D"MsoNormal">to the 'Headend'. <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Regarding Multi-level-encapsulation:<o:p></o:p></p> <p class=3D"MsoNormal">Again this is v00. First, let's discuss the expected= behavior.<o:p></o:p></p> <p class=3D"MsoNormal">Draft-ali refers only to TI-LFA without any illustra= tion <o:p> </o:p></p> <p class=3D"MsoNormal">(which is absolutely fine by me in the current discu= ssion <o:p> </o:p></p> <p class=3D"MsoNormal">phase). TI-LFA is covered by draft-varhal as well. T= he<o:p></o:p></p> <p class=3D"MsoNormal">more transport outer IPv6 headers preceding the cust= omer's <o:p> </o:p></p> <p class=3D"MsoNormal">inner IPv6 header, the more sophisticated inspection= is <o:p> </o:p></p> <p class=3D"MsoNormal">needed on the invoking packet ...<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Regarding MPLS/SRv6 scenarios:<o:p></o:p></p> <p class=3D"MsoNormal">Again this is v00. First, let's discuss the expected= behavior.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Cheers<o:p></o:p></p> <p class=3D"MsoNormal">Bala'zs<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri",sans-serif">From:</span></b><span style=3D"font-size:11.0pt;= font-family:"Calibri",sans-serif"> Krzysztof Szarkowicz <kszar= [email protected]> <br> <b>Sent:</b> Wednesday, March 4, 2026 10:29 AM<br> <b>To:</b> Joel Halpern <[email protected]><br> <b>Cc:</b> Bal=E1zs Varga A <[email protected]>; IPv6 List = <[email protected]><br> <b>Subject:</b> Re: [IPv6]Re: New draft: draft-varhal-6man-icmp-srv6-vpn-00= .txt<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Joel,<o:p></o:p></p> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Of course, in case of network failures (or configura= tion mistakes ?) causing no reachability to the egress or ingress, it will = affect traceroute operation. In case when on ‘P’ node reachabil= ity to egress fails, it affects solution described in draft-ali-6man-srv6-vpn-icmp-error-handling. In case when on ̵= 6;P’ node reachability to ingress fails, it affects solution describe= d in draft-varhal-6man-icmp-srv6-vpn.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">There are no miracles here, in fact.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Best regards,<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">Krzysztof<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><br> <br> <o:p></o:p></p> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <p class=3D"MsoNormal">On 2026 Mar 2, at 19:13, Joel Halpern <<a href=3D= "mailto:[email protected]">[email protected]</a>> wrote:<o:p></o:p><= /p> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <div> <p>Do you consider it to be a feature or a drawback of the MPLS solution th= at 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 MP= LS case. From where I sit, it is a drawback. And one we can address in the SRv6 case.<o:p></o:p></p> <p>Yours,<o:p></o:p></p> <p>Joel<o:p></o:p></p> <div> <p class=3D"MsoNormal">On 3/2/2026 12:54 PM, Krzysztof Szarkowicz wrote:<o:= p></o:p></p> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Hi Bal=E1zs, <o:p></o:p></p> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Thank you for your response. Appreciated.<o:p></o:p>= </p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Please see inline my comments.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Cheers,<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">Krzysztof<o:p></o:p></p> <div> <p class=3D"MsoNormal"><br> <br> <o:p></o:p></p> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <p class=3D"MsoNormal">On 2026 Feb 27, at 17:22, Bal=E1zs Varga A <a href= =3D"mailto:[email protected]"> <[email protected]></a> wrote:<o:p></o:p></p> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <div> <p class=3D"MsoNormal">Hi Krzysztof,<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">the purpose of the draft is to provide a solution to= ICMP Error<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">Handling for VPNs in SRv6 Networks without the short= comings of<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">MPLS like approaches. <o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">[Krzysztof] That is interesting, that we came to dif= ferent conclusions, regarding shortcomings of the solution :-).<o:p></o:p><= /p> </div> <p class=3D"MsoNormal"><br> <br> <o:p></o:p></p> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal">Furthermore, it proposes new functionality<o:p></o:p= ></p> </div> <div> <p class=3D"MsoNormal">only on the PE nodes. No P nodes are affected. P nod= es can be<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">standard compliant IPv6-only nodes. No change of the= widely<span class=3D"apple-converted-space"> </span><o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">implemented ICMPv6 processing (RFC4443) is needed on= them.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">[Krzysztof] Authors of the competitive solution (dra= ft-ali-6man-srv6-vpn-icmp-error-handling) propose only change on P nodes (n= o change on PE nodes). In typical network, there is more PE nodes than P no= des. In any case, changes to the current behavior are needed (either on P or on PE). And, that is the reason for cr= eating new standards. But, it doesn’t really matter here, actually. M= ore important are shortcomings of one versus another solution.<o:p></o:p></= p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">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 g= iving more details, what does it mean. So, if P node has a valid IPv4 addre= ss (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. Si= milarly, 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 t= he traceroute output on the invoking node). Both of these shortcomings are = resolved in the competitive draft.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">As stated in Section 3.2 of the draft:<o:p></o:p></p= > </div> <div> <p class=3D"MsoNormal">2. PE1 encapsulates the packet in an SRv6 tunn= el (Uniform model<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"> used). Th= e srcIP of the encapsulation is a VPN specific SID of<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"> PE1.<o:p></o:p>= </p> </div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">The solution works for any VPN setup including hub-a= nd-spoke<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">L3VPN. ICMP error generated for packets sent by PE1 = (i.e., originated<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">from PE1 hosts) are sent to PE1 and PE1 can send it = to connected<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">hosts. As only PE1 and P2 nodes are involved it work= s for any VPN<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">topologies.<o:p></o:p></p> </div> </div> </blockquote> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">[Krzysztof] In case of hub-and-spoke topologies, whe= re 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 trav= erse the hub site - i.e. for security screening), traffic arrived from CEs in VRF-in is forced to VRF-out, and r= outed based on the routing table in VRF-out (which has in principle only de= fault 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 e= rror message arrives to VRF-out (based on principles described in draft-var= hal-6man-icmp-srv6-vpn-00), it has only default route pointing to VRF-hub o= n remote PE (no connected routes). This ICMP Error Message will be blackholed, IMHO. Or, authors of draf= t-varhal-6man-icmp-srv6-vpn plan to describe in details, how to handle such= hub-and-spoke scenario?<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">This shortcoming is as well natively resolved in the= competitive proposal.<o:p></o:p></p> </div> <p class=3D"MsoNormal"><br> <br> <o:p></o:p></p> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <p class=3D"MsoNormal">Similarly, the solution is transparent to the SRv6 p= olicies used in a<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">given network scenario. If someone is using SR polic= ies for VPN traffic<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">on e.g., PE1, the structure of SR policy in RFC 9256= (Section 2.13) still<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">applies. The Headend node is still PE1, why should i= t be VPN specific?<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">For example Section 8.4 of RFC 9256 clearly defines = the usage of the<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">SR policy information model. Segment list of the SR = Policy is pushed<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">to the encapsulated packet (e.g., in the SRH).<o:p><= /o:p></p> </div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">RFC9256 does not states, that the PE should use is t= he headend from<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">the SR policy as a srcIP.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">So, no need to create 2k SRv6 policies per remote PE= (Endpoint), with<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">exactly the same content. The ‘Headend’ = refers to PE1 not the VPN.<o:p></o:p></p> </div> </blockquote> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">[Krzysztof] Virtually all SRv6 policy implementation= s I am aware of, implements SRv6 policy as some sort of IP tunnel, with sou= rce address of this tunnel equal to ‘Headend’ (typically: loopb= ack) from SRv6 policy definition. My understanding is, that authors of draft-ali-6man-srv6-vpn-icmp-error-handling promote di= sconnection between ‘Headend’ defined on SRv6 policy, and encap= sulation of that SRv6 policy (specifically: source IP address will differ f= rom ‘Headend’).<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">The competitive proposal doesn’t have this sho= rtcoming, and keeps the consistent association between SRv6 policy ‘h= eadend’ and the encapsulation (source IP is equal to ‘headend&#= 8217;).<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Further shortcomings with draft-varhal-6man-icmp-srv= 6-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 (typical= ly - loopback). draft-varhal-6man-icmp-srv6-vpn doesn’t describe= , how to handle such scenarios. Competitive draft handles such scenarios natively.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <p class=3D"MsoNormal">Also, I don’t see in the draft any discussion = regarding mixed MPLS/SRv6 scenarios (i.e. during migration), where either M= PLS is tunneled over SRv6 (Mo6), or the opposite (6oM), or some sort of enc= apsulation conversion between MPLS and SRv6 is done (draft-ietf-spring-srv6-mpls-interworking). While competitive draf= t handles these scenarios natively, I am not sure, how such scenarios will = be handled using the principles described in draft-varhal-6man-icmp-srv6-vp= n.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">The above shortcomings of the solution described in = draft-varhal-6man-icmp-srv6-vpn, while similar solution was initially as we= ll 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 s= hortcomings mentioned above.<br> <br> <o:p></o:p></p> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">Cheers<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">Bala’zs<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <div> <div style=3D"border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0= in 0in 0in;border-color:currentcolor currentcolor;border-image: none"> <div> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri",sans-serif">From:</span></b><span class=3D"apple-converted-s= pace"><span style=3D"font-size:11.0pt;font-family:"Calibri",sans-= serif"> </span></span><span style=3D"font-size:11.0pt;font-family:&quo= t;Calibri",sans-serif">Krzysztof Szarkowicz <a href=3D"mailto:[email protected]"><kszarkowicz@gmail.= com></a><br> <b>Sent:</b><span class=3D"apple-converted-space"> </span>Thursday, Fe= bruary 26, 2026 7:07 PM<br> <b>To:</b><span class=3D"apple-converted-space"> </span>Bal=E1zs Varga= A <a href=3D"mailto:[email protected]"> <[email protected]></a><br> <b>Cc:</b><span class=3D"apple-converted-space"> </span>IPv6 List <a h= ref=3D"mailto:[email protected]"> <[email protected]></a>; Mr. Zafar Ali <a href=3D"mailto:[email protected]">= <[email protected]></a><br> <b>Subject:</b><span class=3D"apple-converted-space"> </span>Re: [IPv6= ]New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt</span><o:p></o:p></p> </div> </div> </div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">Hi Bal=E1zs,<o:p></o:p></p> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">Further question: how it will work with SRv6 policie= s? RFC 9256 (Section 2.13)specifies SR policy as follows:<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal" style=3D"background:white"><b><span style=3D"font-fa= mily:Consolas;color:#20252A">SR Policy POL1</span></b><o:p></o:p></p> </div> <div style=3D"margin-left:.5in"> <p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-famil= y:Consolas;color:#20252A"><Headend =3D H1, Color =3D 1, Endpoint =3D E1&= gt;</span><o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"background:white"><b><span style=3D"font-fa= mily:Consolas;color:#20252A">Candidate Path CP1</span></b><o:p></o:p></p> </div> <div style=3D"margin-left:.5in"> <p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-famil= y:Consolas;color:#20252A"><Protocol-Origin =3D 20, Originator =3D 64511:= 192.0.2.1, Discriminator =3D 1></span><o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"background:white"><b><span style=3D"font-fa= mily:Consolas;color:#20252A">Preference</span></b><o:p></o:p></p> </div> <div style=3D"margin-left:.5in"> <p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-famil= y:Consolas;color:#20252A">200</span><o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"background:white"><b><span style=3D"font-fa= mily:Consolas;color:#20252A">Priority</span></b><o:p></o:p></p> </div> <div style=3D"margin-left:.5in"> <p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-famil= y:Consolas;color:#20252A">10</span><o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"background:white"><b><span style=3D"font-fa= mily:Consolas;color:#20252A">Segment List 1</span></b><o:p></o:p></p> </div> <div style=3D"margin-left:.5in"> <p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-famil= y:Consolas;color:#20252A"><SID11...SID1i>, Weight W1</span><o:p></o:p= ></p> </div> <div> <p class=3D"MsoNormal" style=3D"background:white"><b><span style=3D"font-fa= mily:Consolas;color:#20252A">Segment List 2</span></b><o:p></o:p></p> </div> <div style=3D"margin-left:.5in"> <p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-famil= y:Consolas;color:#20252A"><SID21...SID2j>, Weight W2</span><o:p></o:p= ></p> </div> <div> <p class=3D"MsoNormal" style=3D"background:white"><b><span style=3D"font-fa= mily:Consolas;color:#20252A">Candidate Path CP2</span></b><o:p></o:p></p> </div> <div style=3D"margin-left:.5in"> <p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-famil= y:Consolas;color:#20252A"><Protocol-Origin =3D 20, Originator =3D 64511:= 192.0.2.2, Discriminator =3D 2></span><o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"background:white"><b><span style=3D"font-fa= mily:Consolas;color:#20252A">Preference</span></b><o:p></o:p></p> </div> <div style=3D"margin-left:.5in"> <p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-famil= y:Consolas;color:#20252A">100</span><o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"background:white"><b><span style=3D"font-fa= mily:Consolas;color:#20252A">Priority</span></b><o:p></o:p></p> </div> <div style=3D"margin-left:.5in"> <p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-famil= y:Consolas;color:#20252A">10</span><o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"background:white"><b><span style=3D"font-fa= mily:Consolas;color:#20252A">Segment List 3</span></b><o:p></o:p></p> </div> <div style=3D"margin-left:.5in"> <p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-famil= y:Consolas;color:#20252A"><SID31...SID3i>, Weight W3</span><o:p></o:p= ></p> </div> <div> <p class=3D"MsoNormal" style=3D"background:white"><b><span style=3D"font-fa= mily:Consolas;color:#20252A">Segment List 4</span></b><o:p></o:p></p> </div> <div style=3D"margin-left:.5in"> <p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-famil= y:Consolas;color:#20252A"><SID41...SID4j>, Weight W4</span><o:p></o:p= ></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">So, having for example 2k VPNs, will we need to crea= te 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?<o:p></o:= p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">Cheers,<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">Krzysztof<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <div> <div> <p class=3D"MsoNormal"><br> <br> <br> <o:p></o:p></p> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal">On 2026 Feb 26, at 12:35, Krzysztof Szarkowicz <<= a href=3D"mailto:[email protected]">[email protected]</a>> wrote= :<o:p></o:p></p> </div> </div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <div> <div> <div> <p class=3D"MsoNormal">Hi Bal=E1zs.<o:p></o:p></p> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">‘VPN specific SID’ is not present in the= srcIP of the invoking SRv6 packet. srcIP of the invoking SRv6 packet is ty= pically loopback (or local locator), and the same srcIP is used for transpo= rting traffic of all VPNs on given PE node.<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">Or, the purpose of the draft, is to mandate that dif= ferent source is used per VPN (current SRv6 implementations don’t do = that).<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">How your draft will handle hub-and-spoke L3VPN deplo= yments, where PE1 hosts spoke VRF, and - apart from locally connected route= s - the only route in that VRF is default route pointing to hub VRF (which = resides on PE2)?<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">Cheers,<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">Krzysztof<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <div> <div> <p class=3D"MsoNormal"><br> <br> <br> <o:p></o:p></p> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal">On 2026 Feb 26, at 12:04, Bal=E1zs Varga A <<a hr= ef=3D"mailto:[email protected]">[email protected]</a>&g= t; wrote:<o:p></o:p></p> </div> </div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> <div> <div> <div> <p class=3D"MsoNormal">Hi Krzysztof,<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">Thanks for the note. Yes, we are aware of the MPLS a= pproach like draft.<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">With our proposal we intend to get rid of the shortc= omings of an MPLS<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">like solution.<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">Regarding your question:<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">At P2 the ‘VPN specific SID’ is present = in the srcIP of the invoking SRv6<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">packet. P2 is not service aware. P2 just does RFC444= 3 by copying the srcIP<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">of the invoking packet to the dstIP of the generated= ICMP error message.<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">No extra functionality is needed on the P2 node.<o:p= ></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">Thanks & Cheers<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal">Bala’zs<o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div style=3D"border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0= in 0in 0in;border-color:currentcolor;border-image: none"> <div> <div> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri",sans-serif">From:</span></b><span class=3D"apple-converted-s= pace"><span style=3D"font-size:11.0pt;font-family:"Calibri",sans-= serif"> </span></span><span style=3D"font-size:11.0pt;font-family:&quo= t;Calibri",sans-serif">Krzysztof Szarkowicz <<a href=3D"mailto:[email protected]">kszarkowicz@gmail.= com</a>><br> <b>Sent:</b><span class=3D"apple-converted-space"> </span>Thursday, Fe= bruary 26, 2026 9:56 AM<br> <b>To:</b><span class=3D"apple-converted-space"> </span>Bal=E1zs Varga= A <<a href=3D"mailto:[email protected]">balazs.a.varga@ericss= on.com</a>><br> <b>Cc:</b><span class=3D"apple-converted-space"> </span>IPv6 List <= <a href=3D"mailto:[email protected]">[email protected]</a>>; Mr. Zafar Ali <<= a href=3D"mailto:[email protected]">[email protected]</a>><br> <b>Subject:</b><span class=3D"apple-converted-space"> </span>Re: [IPv6= ]New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt</span><o:p></o:p></p> </div> </div> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <table class=3D"MsoNormalTable" border=3D"0" cellspacing=3D"0" cellpadding= =3D"0" align=3D"left" width=3D"100%" style=3D"width:100.0%"> <tbody> <tr> <td width=3D"0" style=3D"width:.3pt;background:#A6A6A6;padding:5.25pt 1.5pt= 5.25pt 1.5pt"> </td> <td width=3D"100%" style=3D"width:100.0%;padding:0in 0in 0in 0in;aspect-rat= io: revert !important;background:revert !important;block-size: revert !impo= rtant;border:revert !important;bottom: revert !important;color:revert !impo= rtant;color-scheme: revert !important;content-visibility: revert !important= ;cursor:revert !important;direction:revert !important;display:revert !impor= tant;font-size:revert !important;height:revert !important;hyphens: revert != important;letter-spacing:revert !important;line-height:revert !important;ma= rgin:revert !important;opacity: revert !important;order: revert !important;= outline: revert !important;overflow:revert !important;padding:revert !impor= tant;position:revert !important;resize: revert !important;rotate: revert !i= mportant;scale: revert !important;tab-size: revert !important;table-layout:= revert !important;text-align:revert !important;text-indent:revert !importan= t;text-orientation: revert !important;text-overflow: revert !important;text= -shadow:revert !important;text-transform:revert !important;text-wrap: rever= t !important;top:revert !important;transition: revert !important;vertical-a= lign:revert !important;visibility:revert !important;white-space:revert !imp= ortant;width:revert !important;word-break:revert !important;word-spacing:re= vert !important;writing-mode:revert !important;zoom: revert !important"> <div> <div> <div> <p class=3D"MsoNormal" style=3D"mso-element:frame;mso-element-frame-hspace:= 2.25pt;mso-element-wrap:around;mso-element-anchor-vertical:paragraph;mso-el= ement-anchor-horizontal:column;mso-height-rule:exactly"> <span lang=3D"DE" style=3D"font-size:9.0pt;font-family:"Segoe UI"= ,sans-serif;color:#212121">Ritk=E1n kap e-mailt a(z)<span class=3D"apple-co= nverted-space"> </span></span><span style=3D"font-size:9.0pt;font-fami= ly:"Segoe UI",sans-serif;color:#212121"><a href=3D"mailto:kszarko= [email protected]"><span lang=3D"DE">[email protected]</span></a></span><s= pan class=3D"apple-converted-space"><span lang=3D"DE" style=3D"font-size:9.= 0pt;font-family:"Segoe UI",sans-serif;color:#212121"> </span= ></span><span lang=3D"DE" style=3D"font-size:9.0pt;font-family:"Segoe = UI",sans-serif;color:#212121">e-mail-c=EDmr=F5l.<span class=3D"apple-c= onverted-space"> </span></span><span style=3D"font-size:9.0pt;font-fam= ily:"Segoe UI",sans-serif;color:#212121"><a href=3D"https://aka.m= s/LearnAboutSenderIdentification">Tudja meg, mi=E9rt fontos ez</a></span><o:p></o:p></p> </div> </div> </div> </td> <td width=3D"75" style=3D"width:56.25pt;padding:0in 0in 0in 0in;aspect-rati= o: revert !important;background:revert !important;block-size: revert !impor= tant;border:revert !important;bottom: revert !important;color:revert !impor= tant;color-scheme: revert !important;content-visibility: revert !important;= cursor:revert !important;direction:revert !important;display:revert !import= ant;font-size:revert !important;height:revert !important;hyphens: revert !i= mportant;letter-spacing:revert !important;line-height:revert !important;mar= gin:revert !important;opacity: revert !important;order: revert !important;o= utline: revert !important;overflow:revert !important;padding:revert !import= ant;position:revert !important;resize: revert !important;rotate: revert !im= portant;scale: revert !important;tab-size: revert !important;table-layout:r= evert !important;text-align:revert !important;text-indent:revert !important= ;text-orientation: revert !important;text-overflow: revert !important;text-= shadow:revert !important;text-transform:revert !important;text-wrap: revert= !important;top:revert !important;transition: revert !important;vertical-al= ign:revert !important;visibility:revert !important;white-space:revert !impo= rtant;width:revert !important;word-break:revert !important;word-spacing:rev= ert !important;writing-mode:revert !important;zoom: revert !important"> </td> </tr> </tbody> </table> <div> <div> <div> <p class=3D"MsoNormal">Hi Bal=E1zs,<span class=3D"apple-converted-space">&n= bsp;</span><o:p></o:p></p> </div> </div> <div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> </div> <div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> </div> <div> <div> <div> <p class=3D"MsoNormal">Please note, there is another draft on this topic al= ready: <a href=3D"https://datatracker.ietf.org/doc/draft-ali-6man-srv6= -vpn-icmp-error-handling/">https://datatracker.ietf.org/doc/draft-ali-6man-= srv6-vpn-icmp-error-handling/</a><o:p></o:p></p> </div> </div> </div> <div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> </div> <div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> </div> <div> <div> <div> <p class=3D"MsoNormal">Regarding your draft, 4th step of the procedure:<o:p= ></o:p></p> </div> </div> </div> <div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> </div> <div> <div> <div> <p class=3D"MsoNormal">>> P2 generates an ICMP Error Message and= sends it to PE1, using the VPN specific SID as a dstIP.<o:p></o:p></p> </div> </div> </div> <div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> </div> <div> <div> <div> <p class=3D"MsoNormal">How P2 know the ‘VPN specific SID’?<o:p>= </o:p></p> </div> </div> </div> <div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> </div> <div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> </div> <div> <div> <div> <p class=3D"MsoNormal">Cheers,<o:p></o:p></p> </div> </div> </div> <div> <div> <div> <p class=3D"MsoNormal">Krzysztof<o:p></o:p></p> </div> </div> <div> <div> <div> <p class=3D"MsoNormal"><br> <br> <br> <br> <o:p></o:p></p> </div> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <div> <div> <p class=3D"MsoNormal">On 2026 Feb 25, at 09:17, Bal=E1zs Varga A <<a hr= ef=3D"mailto:[email protected]">balazs.a.varga= [email protected]</a>> wrote:<o:p></o:p></p> </div> </div> </div> <div> <div> <p class=3D"MsoNormal"> <o:p></o:p></p> </div> </div> <div> <div> <div> <div> <p class=3D"MsoNormal">Hi,<br> <br> We have uploaded a new draft on "ICMP Error Handling for VPNs in SRv6 = Networks".<br> The draft proposes a solution that provides a native IPv6 method what does = NOT have<br> the drawbacks inherited by methods based on the MPLS based VPN ping or trac= eroute<br> concept.<br> <br> It solves the problem that P nodes are not VPN aware without sending the IC= MP error<br> message to the egress PE router for a VPN lookup. It makes P nodes service = agnostic<br> and allows building IPv6-only core networks.<br> <br> Comments and suggestions are welcome.<br> <br> Thanks & Cheers<br> Bala'zs<br> <br> -----Original Message-----<br> From:<span class=3D"apple-converted-space"> </span><a href=3D"mailto:i= [email protected]">[email protected]</a><span class=3D"apple-c= onverted-space"> </span><<a href=3D"mailto:[email protected]= ">[email protected]</a>><br> Sent: Wednesday, February 25, 2026 8:07 AM<br> To: Bal=E1zs Varga A <<a href=3D"mailto:[email protected]">bal= [email protected]</a>>; Joel Halpern <<a href=3D"mailto:joel.h= [email protected]">[email protected]</a>><br> Subject: New Version Notification for draft-varhal-6man-icmp-srv6-vpn-00.tx= t<br> <br> 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 reposito= ry.<br> <br> Name: draft-varhal-6man-icmp-srv6-vpn<br> Revision: 00<br> Title: ICMP Error Handling for VPNs in SRv6 Networks<br> Date: 2026-02-24<br> Group: Individual Submission<br> Pages: 7<br> URL: <a href=3D"https://www.ietf.org/archive/= id/draft-varhal-6man-icmp-srv6-vpn-00.txt">https://www.ietf.org/archive/id/= draft-varhal-6man-icmp-srv6-vpn-00.txt</a><br> Status: <a href=3D"https://datatracker.ietf.org/doc/draft-varha= l-6man-icmp-srv6-vpn/">https://datatracker.ietf.org/doc/draft-varhal-6man-i= cmp-srv6-vpn/</a><br> HTMLized:<span class=3D"apple-converted-space"> </span><a href=3D"http= s://datatracker.ietf.org/doc/html/draft-varhal-6man-icmp-srv6-vpn">https://= datatracker.ietf.org/doc/html/draft-varhal-6man-icmp-srv6-vpn</a><br> <br> <br> Abstract:<br> <br> This document specifies ICMP error handling in SRv6-based Virtu= al<br> Private Networks.<br> <br> <br> <br> The IETF Secretariat<br> <br> <br> --------------------------------------------------------------------<br> IETF IPv6 working group mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><br> List Info:<span class=3D"apple-converted-space"> </span><a href=3D"htt= ps://mailman3.ietf.org/mailman3/lists/[email protected]/">https://mailman3.ietf= .org/mailman3/lists/[email protected]/</a><br> --------------------------------------------------------------------<o:p></= o:p></p> </div> </div> </div> </div> </blockquote> </div> </div> </div> </div> </blockquote> </div> </div> </div> </div> </blockquote> </div> </div> </blockquote> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <p class=3D"MsoNormal"><br> <br> <o:p></o:p></p> <pre>--------------------------------------------------------------------<o= :p></o:p></pre> <pre>IETF IPv6 working group mailing list<o:p></o:p></pre> <pre><a href=3D"mailto:[email protected]">[email protected]</a><o:p></o:p></pre> <pre>List Info: <a href=3D"https://mailman3.ietf.org/mailman3/lists/ipv6@ie= tf.org/">https://mailman3.ietf.org/mailman3/lists/[email protected]/</a><o:p></= o:p></pre> <pre>--------------------------------------------------------------------<o= :p></o:p></pre> </blockquote> </div> </div> </blockquote> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </div> </body> </html> --_000_AM0PR07MB593888E187A0D61A0A17BF24AC7CAAM0PR07MB5938eurp_-- --===============6609350965226026240== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5nIG1h aWxpbmcgbGlzdCAtLSBzcHJpbmdAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp bCB0byBzcHJpbmctbGVhdmVAaWV0Zi5vcmcK --===============6609350965226026240==--