[spring] Re: [IPv6]Re: New draft: draft-varhal-6man- icmp-srv6-vpn-00.txt
Krzysztof Szarkowicz <[email protected]> Thu, 5 Mar 2026 13:51:55 +0100
| Newsgroups | gmane.ietf.spring,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <[email protected]> |
--===============4647338382023828717== Content-Type: multipart/alternative; boundary="Apple-Mail=_349E8E57-714A-49C5-AA1D-7738B7DECE4B" --Apple-Mail=_349E8E57-714A-49C5-AA1D-7738B7DECE4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bal=C3=A1zs, 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=C3=A1zs Varga A = <[email protected]> wrote: >=20 > Hi Krzysztof, > =20 > many thanks for your effort to verify the applicability of=20 > 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. > =20 > I think we need to apply same objective judgment rules for=20 > 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=20 > solve. :--)) > =20 > You may explain more about "similar solution was initially=20 > as well discussed among authors of draft-ali" on the list. > That would help a better understanding by the WG. > =20 > Reactions to the technical comments done below. > =20 > Regarding IPv4 handling: > Yes, it needs further text. Your assumption and judgement > on how it is provided by draft-varhal is not correct. The=20 > solution is based on RFC7600 (btw, similar to the method=20 > described in draft-ali). Anyway, point taken, a detailed=20 > description is needed in the next version. > =20 > 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=20 > nodes are reachable via vrf-in, SID(s) is announced for=20 > remote PE nodes from vrf-in. No SID allocation is needed > for vrf-out. Draft-varhal states that a VPN-specific-SID=20 > is used as srcIP. Here, the VPN-specific-SID is the SID > allocated for vrf-in, so the ICMP error message arrives=20 > to vrf-in and is NOT backholed.=20 > 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? > =20 > Regarding SRv6 policy (+ VPN): > I strongly disagree with your view, you are you conflating > things here and making invalid assumptions on draft-varhal.=20 > The encapsulation process on the headend node needs=20 > several input information to construct the outer header.=20 > One group of information is derived from the SR policy. > The SR policy defines the path to which a node steers a=20 > packet flow. Applying a SR policy means to select the path > (defined by a SID list) and placing the path descriptors=20 > into the dstIP and SRH fields of the tunnel encapsulation.=20 > 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=20 > to the 'Headend'.=20 > =20 > 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=20 > (which is absolutely fine by me in the current discussion=20 > phase). TI-LFA is covered by draft-varhal as well. The > more transport outer IPv6 headers preceding the customer's=20 > inner IPv6 header, the more sophisticated inspection is=20 > needed on the invoking packet ... > =20 > Regarding MPLS/SRv6 scenarios: > Again this is v00. First, let's discuss the expected behavior. > =20 > Cheers > Bala'zs > =20 > =20 > =20 > From: Krzysztof Szarkowicz <[email protected]> > Sent: Wednesday, March 4, 2026 10:29 AM > To: Joel Halpern <[email protected]> > Cc: Bal=C3=A1zs Varga A <[email protected]>; IPv6 List = <[email protected]> > Subject: Re: [IPv6]Re: New draft: = draft-varhal-6man-icmp-srv6-vpn-00.txt > =20 > Joel, > =20 > 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 =E2=80=98P=E2=80=99 node = reachability to egress fails, it affects solution described in = draft-ali-6man-srv6-vpn-icmp-error-handling. In case when on =E2=80=98P=E2= =80=99 node reachability to ingress fails, it affects solution described = in draft-varhal-6man-icmp-srv6-vpn. > =20 > There are no miracles here, in fact. > =20 > Best regards, > Krzysztof > =20 >=20 >=20 > On 2026 Mar 2, at 19:13, Joel Halpern <[email protected] = <mailto:[email protected]>> wrote: > =20 > 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. =46rom where I sit, it is a drawback. And one we can = address in the SRv6 case. >=20 > Yours, >=20 > Joel >=20 > On 3/2/2026 12:54 PM, Krzysztof Szarkowicz wrote: > Hi Bal=C3=A1zs,=20 > =20 > =20 > Thank you for your response. Appreciated. > =20 > Please see inline my comments. > =20 > =20 > Cheers, > Krzysztof >=20 >=20 > On 2026 Feb 27, at 17:22, Bal=C3=A1zs Varga A = <[email protected]> <mailto:[email protected]> = wrote: > =20 > Hi Krzysztof, > =20 > 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.=20 > =20 > [Krzysztof] That is interesting, that we came to different = conclusions, regarding shortcomings of the solution :-). >=20 >=20 > 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=20 > implemented ICMPv6 processing (RFC4443) is needed on them. > =20 > [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=E2=80=99t really matter here, actually. More = important are shortcomings of one versus another solution. > =20 > 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).=E2=80=9D, 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 =E2=80=98IPv6-to-IPv4 translated = address=E2=80=99, instead of real IPv4 address of P node. Similarly, if = P node has only IPv6 address, again the invoking node gets only some = =E2=80=98IPv6-to-IPv4 translated address=E2=80=99, 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. > =20 > =20 > 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. > =20 > 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. > =20 > [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=E2=80=99s 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? > =20 > This shortcoming is as well natively resolved in the competitive = proposal. >=20 >=20 > 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). > =20 > RFC9256 does not states, that the PE should use is the headend from > the SR policy as a srcIP. > =20 > So, no need to create 2k SRv6 policies per remote PE (Endpoint), with > exactly the same content. The =E2=80=98Headend=E2=80=99 refers to PE1 = not the VPN. > =20 > [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 =E2=80=98Headend=E2=80=99 (typically: loopback) = from SRv6 policy definition. My understanding is, that authors of = draft-ali-6man-srv6-vpn-icmp-error-handling promote disconnection = between =E2=80=98Headend=E2=80=99 defined on SRv6 policy, and = encapsulation of that SRv6 policy (specifically: source IP address will = differ from =E2=80=98Headend=E2=80=99). > =20 > The competitive proposal doesn=E2=80=99t have this shortcoming, and = keeps the consistent association between SRv6 policy =E2=80=98headend=E2=80= =99 and the encapsulation (source IP is equal to =E2=80=98headend=E2=80=99= ). > =20 > =20 > 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=E2=80=99t 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=E2=80=99t describe, how to handle = such scenarios. Competitive draft handles such scenarios natively. > =20 > Also, I don=E2=80=99t 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. > =20 > 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=E2=80=99t have shortcomings mentioned above. >=20 > =20 > Cheers > Bala=E2=80=99zs > =20 > =20 > From: Krzysztof Szarkowicz <[email protected]> = <mailto:[email protected]> > Sent: Thursday, February 26, 2026 7:07 PM > To: Bal=C3=A1zs 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 > =20 > Hi Bal=C3=A1zs, > =20 > =20 > Further question: how it will work with SRv6 policies? RFC 9256 = (Section 2.13)specifies SR policy as follows: > =20 > 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 > =20 > =20 > So, having for example 2k VPNs, will we need to create 2k SRv6 = policies per remote PE (Endpoint), with exactly the same content, except = =E2=80=98Headend=E2=80=99? As, I assume, in the =E2=80=98Headend=E2=80=99,= we will need to encode =E2=80=98VPN specific SID=E2=80=99? And, each = time some VPN is added/removed, SRv6 Policy needs to be added/removed? > =20 > =20 > =20 > =20 > Cheers, > Krzysztof > =20 >=20 >=20 >=20 > On 2026 Feb 26, at 12:35, Krzysztof Szarkowicz <[email protected] = <mailto:[email protected]>> wrote: > =20 > Hi Bal=C3=A1zs. > =20 > =20 > =E2=80=98VPN specific SID=E2=80=99 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. > =20 > Or, the purpose of the draft, is to mandate that different source is = used per VPN (current SRv6 implementations don=E2=80=99t do that). > =20 > 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)? > =20 > =20 > Cheers, > Krzysztof > =20 >=20 >=20 >=20 > On 2026 Feb 26, at 12:04, Bal=C3=A1zs Varga A = <[email protected] <mailto:[email protected]>> = wrote: > =20 > Hi Krzysztof, > =20 > 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. > =20 > Regarding your question: > At P2 the =E2=80=98VPN specific SID=E2=80=99 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. > =20 > Thanks & Cheers > Bala=E2=80=99zs > =20 > =20 > From: Krzysztof Szarkowicz <[email protected] = <mailto:[email protected]>> > Sent: Thursday, February 26, 2026 9:56 AM > To: Bal=C3=A1zs 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 > =20 > Ritk=C3=A1n kap e-mailt a(z) [email protected] = <mailto:[email protected]> e-mail-c=C3=ADmr=C5=91l. Tudja meg, = mi=C3=A9rt fontos ez <https://aka.ms/LearnAboutSenderIdentification>=09 > Hi Bal=C3=A1zs,=20 > =20 > =20 > Please note, there is another draft on this topic already: = https://datatracker.ietf.org/doc/draft-ali-6man-srv6-vpn-icmp-error-handli= ng/ > =20 > =20 > Regarding your draft, 4th step of the procedure: > =20 > >> P2 generates an ICMP Error Message and sends it to PE1, using the = VPN specific SID as a dstIP. > =20 > How P2 know the =E2=80=98VPN specific SID=E2=80=99? > =20 > =20 > Cheers, > Krzysztof >=20 >=20 >=20 >=20 > On 2026 Feb 25, at 09:17, Bal=C3=A1zs Varga A = <[email protected] = <mailto:[email protected]>> wrote: > =20 > Hi, >=20 > 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. >=20 > 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. >=20 > Comments and suggestions are welcome. >=20 > Thanks & Cheers > Bala'zs >=20 > -----Original Message----- > From: [email protected] <mailto:[email protected]> = <[email protected] <mailto:[email protected]>> > Sent: Wednesday, February 25, 2026 8:07 AM > To: Bal=C3=A1zs 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 >=20 > 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. >=20 > 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 >=20 >=20 > Abstract: >=20 > This document specifies ICMP error handling in SRv6-based Virtual > Private Networks. >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] <mailto:[email protected]> > List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/ > -------------------------------------------------------------------- > =20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] <mailto:[email protected]> > List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/ > -------------------------------------------------------------------- --Apple-Mail=_349E8E57-714A-49C5-AA1D-7738B7DECE4B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;">Hi = Bal=C3=A1zs,<div><br></div><div><br></div><div>OK, I will wait for next = revision of the draft, with more details on the issues I = raised.</div><div><br></div><div>Just one comment = inline.</div><div><br></div><div><br></div><div>Cheers,</div><div>Krzyszto= f</div><div><br id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On 2026 Mar 4, at 15:38, Bal=C3=A1zs Varga A = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><meta charset=3D"UTF-8"><div = class=3D"WordSection1" style=3D"page: WordSection1; caret-color: rgb(0, = 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = orphans: 2; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid;"><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Hi Krzysztof,<o:p></o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">many thanks for your = effort to verify the applicability of<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><span lang=3D"DE">draft-varhal-6man-icmp-srv6-vpn.<span = class=3D"Apple-converted-space"> </span></span>Please, note that it = is<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">the first version (v00), so further = details will be added<o:p></o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">in upcoming versions, = based on the valuable inputs from<o:p></o:p></div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">the mailing list = discussions.<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"><o:p> </o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">I think we need to apply same objective judgment rules = for<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">the proposed solutions. I will start a separate mail = thread<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">to clarify the expectations on VPN = ping/trace in SRv6<o:p></o:p></div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif;">networks. It is always good to = agree on WHAT we intend to<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">solve. :--))<o:p></o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">You may explain more = about "similar solution was initially<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">as well discussed among authors of draft-ali" on the = list.<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">That would help a better understanding = by the WG.<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"><o:p> </o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Reactions to the technical comments done = below.<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"><o:p> </o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Regarding IPv4 handling:<o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Yes, it needs further text. Your assumption and = judgement<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">on how it is provided by draft-varhal = is not correct. The<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">solution is based on RFC7600 (btw, similar to the = method<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">described in draft-ali). Anyway, point taken, a = detailed<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">description is needed in the next = version.<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"><o:p> </o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Regarding Hub-and-Spoke VPN:<o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Yes, it needs a specific configuration. The structure = of<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">the used VRFs (i.e., vrf-in, vrf-out) = determine routing<o:p></o:p></div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif;">and reachability of prefixes = within the VPN. Connected<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">nodes are reachable via vrf-in, SID(s) is announced = for<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">remote PE nodes from vrf-in. No SID allocation is = needed<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">for vrf-out. Draft-varhal states that a = VPN-specific-SID<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">is used as srcIP. Here, the VPN-specific-SID is the = SID<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">allocated for vrf-in, so the ICMP error = message arrives<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">to vrf-in and is NOT backholed.<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">This scenario is natively resolved. = ;--))</div></div></div></blockquote><div><br></div><div>[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?</div><br><blockquote = type=3D"cite"><div><div class=3D"WordSection1" style=3D"page: = WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: 2; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-line: = none; text-decoration-thickness: auto; text-decoration-style: = solid;"><div style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p></o:p></div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Regarding SRv6 policy (+ VPN):<o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">I strongly disagree with your view, you are you = conflating<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">things here and making invalid = assumptions on draft-varhal.<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">The encapsulation process on the headend node needs<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">several input information to construct the outer = header.<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">One group of information is derived from the SR = policy.<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">The SR policy defines the path to which = a node steers a<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">packet flow. Applying a SR policy means to select the = path<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">(defined by a SID list) and placing the = path descriptors<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">into the dstIP and SRH fields of the tunnel = encapsulation.<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Another group of information are needed as well, like = srcIP,<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">Traffic Class, FlowLabel, HopLimit, = NextHeader. They are<o:p></o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">derived by other local = functionalities. The srcIP MUST<o:p></o:p></div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">resolve to a = unique node in the SR domain [RFC9256],<o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">what is fulfilled by draft-varhal. The srcIP is = specific<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">to the 'Headend'.<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">Regarding = Multi-level-encapsulation:<o:p></o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">Again this is v00. = First, let's discuss the expected behavior.<o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Draft-ali refers only to TI-LFA without any = illustration<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">(which is absolutely fine by me in the current = discussion<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">phase). TI-LFA is covered by draft-varhal as well. = The<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">more transport outer IPv6 headers = preceding the customer's<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">inner IPv6 header, the more sophisticated inspection = is<span class=3D"Apple-converted-space"> </span><o:p></o:p></div><div= style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">needed on the invoking packet ...<o:p></o:p></div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">Regarding MPLS/SRv6 = scenarios:<o:p></o:p></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">Again this is v00. First, let's discuss = the expected behavior.<o:p></o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;">Cheers<o:p></o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;">Bala'zs<o:p></o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div><div><div style=3D"border-width: 1pt = medium medium; border-style: solid none none; border-color: rgb(225, = 225, 225) currentcolor currentcolor; border-image: none; padding: 3pt = 0in 0in;"><div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;"><b><span style=3D"font-size: 11pt; font-family: = Calibri, sans-serif;">From:</span></b><span style=3D"font-size: 11pt; = font-family: Calibri, sans-serif;"><span = class=3D"Apple-converted-space"> </span>Krzysztof Szarkowicz = <[email protected]><br><b>Sent:</b><span = class=3D"Apple-converted-space"> </span>Wednesday, March 4, 2026 = 10:29 AM<br><b>To:</b><span = class=3D"Apple-converted-space"> </span>Joel Halpern = <[email protected]><br><b>Cc:</b><span = class=3D"Apple-converted-space"> </span>Bal=C3=A1zs Varga A = <[email protected]>; IPv6 List = <[email protected]><br><b>Subject:</b><span = class=3D"Apple-converted-space"> </span>Re: [IPv6]Re: New draft: = draft-varhal-6man-icmp-srv6-vpn-00.txt<o:p></o:p></span></div></div></div>= <div style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;">Joel,<o:p></o:p></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">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 =E2=80=98P=E2=80=99 node reachability to = egress fails, it affects solution described = in draft-ali-6man-srv6-vpn-icmp-error-handling. In case when on = =E2=80=98P=E2=80=99 node reachability to ingress fails, it affects = solution described = in draft-varhal-6man-icmp-srv6-vpn.<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">There are no = miracles here, in fact.<o:p></o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Best = regards,<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;">Krzysztof<o:p></o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><br><br><o:p></o:p></div><blockquote style=3D"margin-top: = 5pt; margin-bottom: 5pt;"><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif;">On 2026 Mar 2, at 19:13, Joel = Halpern <<a href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: underline;">[email protected]</a>> = wrote:<o:p></o:p></div></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"><o:p> </o:p></div><div><div><p>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. =46rom 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><di= v style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">On 3/2/2026 12:54 PM, Krzysztof Szarkowicz = wrote:<o:p></o:p></div></div><blockquote style=3D"margin-top: 5pt; = margin-bottom: 5pt;"><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">Hi Bal=C3=A1zs,<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Thank you for = your response. Appreciated.<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Please see inline = my comments.<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Cheers,<o:p></o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Krzysztof<o:p></o:p></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><br><br><o:p></o:p></div><blockquote style=3D"margin-top: = 5pt; margin-bottom: 5pt;"><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif;">On 2026 Feb 27, at 17:22, Bal=C3=A1= zs Varga A<span class=3D"Apple-converted-space"> </span><a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: = underline;"><[email protected]></a><span = class=3D"Apple-converted-space"> </span>wrote:<o:p></o:p></div></div>= <div style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div><div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">Hi = Krzysztof,<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">the purpose of = the draft is to provide a solution to ICMP = Error<o:p></o:p></div></div><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif;">Handling for VPNs in SRv6 = Networks without the shortcomings of<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">MPLS like approaches.<span = class=3D"Apple-converted-space"> </span><o:p></o:p></div></div></div>= </blockquote><div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"><o:p> </o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">[Krzysztof] That is interesting, that we came to different = conclusions, regarding shortcomings of the solution = :-).<o:p></o:p></div></div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"><br><br><o:p></o:p></div><blockquote = style=3D"margin-top: 5pt; margin-bottom: 5pt;"><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Furthermore, it proposes new = functionality<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">only on the PE nodes. = No P nodes are affected. P nodes can be<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">standard compliant IPv6-only nodes. No change of the = widely<span = class=3D"apple-converted-space"> </span><o:p></o:p></div></div><div><= div style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">implemented ICMPv6 processing (RFC4443) is needed on = them.<o:p></o:p></div></div></div></blockquote><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">[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=E2=80=99t really matter here, actually. More = important are shortcomings of one versus another = solution.<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">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).=E2=80=9D, 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 =E2=80=98IPv6-to-IPv4 translated = address=E2=80=99, instead of real IPv4 address of P node. Similarly, if = P node has only IPv6 address, again the invoking node gets only some = =E2=80=98IPv6-to-IPv4 translated address=E2=80=99, 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.<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><blockquote style=3D"margin-top:= 5pt; margin-bottom: 5pt;"><div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">As stated in = Section 3.2 of the draft:<o:p></o:p></div></div><div><div style=3D"margin:= 0in; font-size: 12pt; font-family: Aptos, sans-serif;">2. PE1 = encapsulates the packet in an SRv6 tunnel (Uniform = model<o:p></o:p></div></div><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, = sans-serif;"> used). The srcIP = of the encapsulation is a VPN specific SID = of<o:p></o:p></div></div><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, = sans-serif;"> = PE1.<o:p></o:p></div></div><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">The solution = works for any VPN setup including = hub-and-spoke<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">L3VPN. ICMP error = generated for packets sent by PE1 (i.e., = originated<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">from PE1 hosts) are = sent to PE1 and PE1 can send it to = connected<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">hosts. As only PE1 and = P2 nodes are involved it works for any = VPN<o:p></o:p></div></div><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, = sans-serif;">topologies.<o:p></o:p></div></div></div></blockquote><div><di= v style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">[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=E2=80=99s 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?<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">This shortcoming = is as well natively resolved in the competitive = proposal.<o:p></o:p></div></div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, = sans-serif;"><br><br><o:p></o:p></div><blockquote style=3D"margin-top: = 5pt; margin-bottom: 5pt;"><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif;">Similarly, the solution is = transparent to the SRv6 policies used in = a<o:p></o:p></div></div><div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">given network scenario. If someone is = using SR policies for VPN traffic<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">on e.g., PE1, the structure of SR policy in RFC 9256 = (Section 2.13) still<o:p></o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">applies. The = Headend node is still PE1, why should it be VPN = specific?<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">For example Section = 8.4 of RFC 9256 clearly defines the usage of = the<o:p></o:p></div></div><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif;">SR policy information model. = Segment list of the SR Policy is pushed<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">to the encapsulated packet (e.g., in the = SRH).<o:p></o:p></div></div><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">RFC9256 does not = states, that the PE should use is the headend = from<o:p></o:p></div></div><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif;">the SR policy as a = srcIP.<o:p></o:p></div></div><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">So, no need to = create 2k SRv6 policies per remote PE (Endpoint), = with<o:p></o:p></div></div><div><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif;">exactly the same content. The = =E2=80=98Headend=E2=80=99 refers to PE1 not the = VPN.<o:p></o:p></div></div></blockquote><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">[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 =E2=80=98Headend=E2=80=99 (typically: loopback) from SRv6 = policy definition. My understanding is, that authors of = draft-ali-6man-srv6-vpn-icmp-error-handling promote disconnection = between =E2=80=98Headend=E2=80=99 defined on SRv6 policy, and = encapsulation of that SRv6 policy (specifically: source IP address will = differ from =E2=80=98Headend=E2=80=99).<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">The competitive = proposal doesn=E2=80=99t have this shortcoming, and keeps the consistent = association between SRv6 policy =E2=80=98headend=E2=80=99 and the = encapsulation (source IP is equal to = =E2=80=98headend=E2=80=99).<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">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=E2=80=99t 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=E2=80=99t describe, how to = handle such scenarios. Competitive draft handles such scenarios = natively.<o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">Also, I don=E2=80=99t = 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.<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">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=E2=80=99t have shortcomings mentioned = above.<br><br><o:p></o:p></div><blockquote style=3D"margin-top: 5pt; = margin-bottom: 5pt;"><div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"> <o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Cheers<o:p></o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Bala=E2=80=99zs<o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div><div><div style=3D"border-width:= 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; = border-color: currentcolor; border-image: none;"><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><b><span style=3D"font-size: 11pt; font-family: Calibri, = sans-serif;">From:</span></b><span class=3D"apple-converted-space"><span = style=3D"font-size: 11pt; font-family: Calibri, = sans-serif;"> </span></span><span style=3D"font-size: 11pt; = font-family: Calibri, sans-serif;">Krzysztof Szarkowicz<span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: = underline;"><[email protected]></a><br><b>Sent:</b><span = class=3D"apple-converted-space"> </span>Thursday, February 26, 2026 = 7:07 PM<br><b>To:</b><span = class=3D"apple-converted-space"> </span>Bal=C3=A1zs Varga A<span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: = underline;"><[email protected]></a><br><b>Cc:</b><span = class=3D"apple-converted-space"> </span>IPv6 List<span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:[email protected]" style=3D"color: blue; text-decoration: = underline;"><[email protected]></a>; Mr. Zafar Ali<span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:[email protected]" style=3D"color: blue; text-decoration: = underline;"><[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></div></div></div>= </div><div><div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;"> <o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Hi Bal=C3=A1zs,<o:p></o:p></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Further question: how it will work with SRv6 policies? RFC = 9256 (Section 2.13)specifies SR policy as = follows:<o:p></o:p></div></div></div><div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif; = background: white;"><b><span style=3D"font-family: Consolas; color: = rgb(32, 37, 42);">SR Policy POL1</span></b><o:p></o:p></div></div><div = style=3D"margin-left: 0.5in;"><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif; background: white;"><span = style=3D"font-family: Consolas; color: rgb(32, 37, 42);"><Headend =3D = H1, Color =3D 1, Endpoint =3D = E1></span><o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif; background: = white;"><b><span style=3D"font-family: Consolas; color: rgb(32, 37, = 42);">Candidate Path CP1</span></b><o:p></o:p></div></div><div = style=3D"margin-left: 0.5in;"><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif; background: white;"><span = style=3D"font-family: Consolas; color: rgb(32, 37, = 42);"><Protocol-Origin =3D 20, Originator =3D 64511:192.0.2.1, = Discriminator =3D 1></span><o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif; = background: white;"><b><span style=3D"font-family: Consolas; color: = rgb(32, 37, 42);">Preference</span></b><o:p></o:p></div></div><div = style=3D"margin-left: 0.5in;"><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif; background: white;"><span = style=3D"font-family: Consolas; color: rgb(32, 37, = 42);">200</span><o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif; background: = white;"><b><span style=3D"font-family: Consolas; color: rgb(32, 37, = 42);">Priority</span></b><o:p></o:p></div></div><div style=3D"margin-left:= 0.5in;"><div style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif; background: white;"><span style=3D"font-family: Consolas; = color: rgb(32, 37, 42);">10</span><o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif; = background: white;"><b><span style=3D"font-family: Consolas; color: = rgb(32, 37, 42);">Segment List 1</span></b><o:p></o:p></div></div><div = style=3D"margin-left: 0.5in;"><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif; background: white;"><span = style=3D"font-family: Consolas; color: rgb(32, 37, = 42);"><SID11...SID1i>, Weight = W1</span><o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif; background: = white;"><b><span style=3D"font-family: Consolas; color: rgb(32, 37, = 42);">Segment List 2</span></b><o:p></o:p></div></div><div = style=3D"margin-left: 0.5in;"><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif; background: white;"><span = style=3D"font-family: Consolas; color: rgb(32, 37, = 42);"><SID21...SID2j>, Weight = W2</span><o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif; background: = white;"><b><span style=3D"font-family: Consolas; color: rgb(32, 37, = 42);">Candidate Path CP2</span></b><o:p></o:p></div></div><div = style=3D"margin-left: 0.5in;"><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif; background: white;"><span = style=3D"font-family: Consolas; color: rgb(32, 37, = 42);"><Protocol-Origin =3D 20, Originator =3D 64511:192.0.2.2, = Discriminator =3D 2></span><o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif; = background: white;"><b><span style=3D"font-family: Consolas; color: = rgb(32, 37, 42);">Preference</span></b><o:p></o:p></div></div><div = style=3D"margin-left: 0.5in;"><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif; background: white;"><span = style=3D"font-family: Consolas; color: rgb(32, 37, = 42);">100</span><o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif; background: = white;"><b><span style=3D"font-family: Consolas; color: rgb(32, 37, = 42);">Priority</span></b><o:p></o:p></div></div><div style=3D"margin-left:= 0.5in;"><div style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif; background: white;"><span style=3D"font-family: Consolas; = color: rgb(32, 37, 42);">10</span><o:p></o:p></div></div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif; = background: white;"><b><span style=3D"font-family: Consolas; color: = rgb(32, 37, 42);">Segment List 3</span></b><o:p></o:p></div></div><div = style=3D"margin-left: 0.5in;"><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif; background: white;"><span = style=3D"font-family: Consolas; color: rgb(32, 37, = 42);"><SID31...SID3i>, Weight = W3</span><o:p></o:p></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif; background: = white;"><b><span style=3D"font-family: Consolas; color: rgb(32, 37, = 42);">Segment List 4</span></b><o:p></o:p></div></div><div = style=3D"margin-left: 0.5in;"><div style=3D"margin: 0in; font-size: = 12pt; font-family: Aptos, sans-serif; background: white;"><span = style=3D"font-family: Consolas; color: rgb(32, 37, = 42);"><SID41...SID4j>, Weight = W4</span><o:p></o:p></div></div></div><div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">So, having for example 2k VPNs, will we need to create 2k = SRv6 policies per remote PE (Endpoint), with exactly the same content, = except =E2=80=98Headend=E2=80=99? As, I assume, in the =E2=80=98Headend=E2= =80=99, we will need to encode =E2=80=98VPN specific SID=E2=80=99? And, = each time some VPN is added/removed, SRv6 Policy needs to be = added/removed?<o:p></o:p></div></div></div><div><div><div style=3D"margin:= 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Cheers,<o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Krzysztof<o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div><div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><br><br><br><o:p></o:p></div></div><blockquote = style=3D"margin-top: 5pt; margin-bottom: 5pt;"><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">On 2026 Feb 26, at 12:35, Krzysztof Szarkowicz <<a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: underline;">[email protected]</a>> = wrote:<o:p></o:p></div></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Hi Bal=C3=A1zs.<o:p></o:p></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">=E2=80=98VPN specific SID=E2=80=99 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.<o:p></o:p></div></div></div><div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Or, the purpose of the draft, is to mandate that different = source is used per VPN (current SRv6 implementations don=E2=80=99t do = that).<o:p></o:p></div></div></div><div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">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)?<o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Cheers,<o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Krzysztof<o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div><div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><br><br><br><o:p></o:p></div></div><blockquote = style=3D"margin-top: 5pt; margin-bottom: 5pt;"><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">On 2026 Feb 26, at 12:04, Bal=C3=A1zs Varga A <<a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: underline;">[email protected]</a>> = wrote:<o:p></o:p></div></div></div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Hi Krzysztof,<o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Thanks for the note. Yes, we are aware of the MPLS approach = like draft.<o:p></o:p></div></div></div><div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">With our proposal = we intend to get rid of the shortcomings of an = MPLS<o:p></o:p></div></div></div><div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">like = solution.<o:p></o:p></div></div></div><div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Regarding your = question:<o:p></o:p></div></div></div><div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">At P2 the =E2=80=98= VPN specific SID=E2=80=99 is present in the srcIP of the invoking = SRv6<o:p></o:p></div></div></div><div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">packet. P2 is not = service aware. P2 just does RFC4443 by copying the = srcIP<o:p></o:p></div></div></div><div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, sans-serif;">of the invoking packet = to the dstIP of the generated ICMP error = message.<o:p></o:p></div></div></div><div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, sans-serif;">No extra = functionality is needed on the P2 = node.<o:p></o:p></div></div></div><div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Thanks & = Cheers<o:p></o:p></div></div></div><div><div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;">Bala=E2=80=99zs<o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div = style=3D"border-width: 1pt medium medium; border-style: solid none none; = padding: 3pt 0in 0in; border-color: currentcolor; border-image: = none;"><div><div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"><b><span style=3D"font-size: 11pt; = font-family: Calibri, sans-serif;">From:</span></b><span = class=3D"apple-converted-space"><span style=3D"font-size: 11pt; = font-family: Calibri, sans-serif;"> </span></span><span = style=3D"font-size: 11pt; font-family: Calibri, sans-serif;">Krzysztof = Szarkowicz <<a href=3D"mailto:[email protected]" style=3D"color: = blue; text-decoration: = underline;">[email protected]</a>><br><b>Sent:</b><span = class=3D"apple-converted-space"> </span>Thursday, February 26, 2026 = 9:56 AM<br><b>To:</b><span = class=3D"apple-converted-space"> </span>Bal=C3=A1zs Varga A <<a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: = underline;">[email protected]</a>><br><b>Cc:</b><span = class=3D"apple-converted-space"> </span>IPv6 List <<a = href=3D"mailto:[email protected]" style=3D"color: blue; text-decoration: = underline;">[email protected]</a>>; Mr. Zafar Ali <<a = href=3D"mailto:[email protected]" style=3D"color: blue; text-decoration: = underline;">[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></div></div></div>= </div></div><div><div><div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><table = class=3D"MsoNormalTable" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" = align=3D"left" width=3D"100%" style=3D"width: 1253px;"><tbody><tr><td = width=3D"0" style=3D"width: 0.3pt; background: rgb(166, 166, 166); = padding: 5.25pt 1.5pt;"></td><td width=3D"100%" style=3D"aspect-ratio: = revert !important; background: revert !important; block-size: revert = !important; border: revert !important; bottom: revert !important; color: = revert !important; color-scheme: revert !important; content-visibility: = revert !important; cursor: revert !important; direction: revert = !important; display: revert !important; font-size: revert !important; = height: revert !important; hyphens: revert !important; letter-spacing: = revert !important; line-height: revert !important; margin: revert = !important; opacity: revert !important; order: revert !important; = outline: revert !important; overflow: revert !important; padding: revert = !important; position: revert !important; resize: revert !important; = rotate: revert !important; scale: revert !important; tab-size: revert = !important; table-layout: revert !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-align: revert !important; visibility: revert !important; = white-space: revert !important; width: revert !important; word-break: = revert !important; word-spacing: revert !important; writing-mode: revert = !important; zoom: revert !important;"><div><div><div><div style=3D"margin:= 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span lang=3D"DE" = style=3D"font-size: 9pt; font-family: "Segoe UI", sans-serif; = color: rgb(33, 33, 33);">Ritk=C3=A1n kap e-mailt a(z)<span = class=3D"apple-converted-space"> </span></span><span = style=3D"font-size: 9pt; font-family: "Segoe UI", sans-serif; = color: rgb(33, 33, 33);"><a href=3D"mailto:[email protected]" = style=3D"color: blue; text-decoration: underline;"><span = lang=3D"DE">[email protected]</span></a></span><span = class=3D"apple-converted-space"><span lang=3D"DE" style=3D"font-size: = 9pt; font-family: "Segoe UI", sans-serif; color: rgb(33, 33, = 33);"> </span></span><span lang=3D"DE" style=3D"font-size: 9pt; = font-family: "Segoe UI", sans-serif; color: rgb(33, 33, = 33);">e-mail-c=C3=ADmr=C5=91l.<span = class=3D"apple-converted-space"> </span></span><span = style=3D"font-size: 9pt; font-family: "Segoe UI", sans-serif; = color: rgb(33, 33, 33);"><a = href=3D"https://aka.ms/LearnAboutSenderIdentification" style=3D"color: = blue; text-decoration: underline;">Tudja meg, mi=C3=A9rt fontos = ez</a></span><o:p></o:p></div></div></div></div></td><td width=3D"75" = style=3D"aspect-ratio: revert !important; background: revert !important; = block-size: revert !important; border: revert !important; bottom: revert = !important; color: revert !important; color-scheme: revert !important; = content-visibility: revert !important; cursor: revert !important; = direction: revert !important; display: revert !important; font-size: = revert !important; height: revert !important; hyphens: revert = !important; letter-spacing: revert !important; line-height: revert = !important; margin: revert !important; opacity: revert !important; = order: revert !important; outline: revert !important; overflow: revert = !important; padding: revert !important; position: revert !important; = resize: revert !important; rotate: revert !important; scale: revert = !important; tab-size: revert !important; table-layout: revert = !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-align: revert !important; = visibility: revert !important; white-space: revert !important; width: = revert !important; word-break: revert !important; word-spacing: revert = !important; writing-mode: revert !important; zoom: revert = !important;"></td></tr></tbody></table><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Hi Bal=C3=A1zs,<span = class=3D"apple-converted-space"> </span><o:p></o:p></div></div></div>= <div><div><div><div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, = sans-serif;"> <o:p></o:p></div></div></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Please note, there is another draft on this topic = already: <a = href=3D"https://datatracker.ietf.org/doc/draft-ali-6man-srv6-vpn-icmp-erro= r-handling/" style=3D"color: blue; text-decoration: = underline;">https://datatracker.ietf.org/doc/draft-ali-6man-srv6-vpn-icmp-= error-handling/</a><o:p></o:p></div></div></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Regarding your draft, 4th step of the = procedure:<o:p></o:p></div></div></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">>> P2 generates an ICMP Error Message and sends = it to PE1, using the VPN specific SID as a = dstIP.<o:p></o:p></div></div></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">How P2 know the =E2=80=98VPN specific = SID=E2=80=99?<o:p></o:p></div></div></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Cheers,<o:p></o:p></div></div></div></div><div><div><div><div= style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">Krzysztof<o:p></o:p></div></div></div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><br><br><br><br><o:p></o:p></div></div></div><blockquote = style=3D"margin-top: 5pt; margin-bottom: 5pt;"><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">On 2026 Feb 25, at 09:17, Bal=C3=A1zs Varga A <<a = href=3D"mailto:[email protected]" = style=3D"color: blue; text-decoration: = underline;">[email protected]</a>> = wrote:<o:p></o:p></div></div></div></div><div><div><div style=3D"margin: = 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"> <o:p></o:p></div></div></div><div><div><div><div><div = style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;">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 = traceroute<br>concept.<br><br>It solves the problem that P nodes are not = VPN aware without sending the ICMP 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:[email protected]" style=3D"color: blue; = text-decoration: underline;">[email protected]</a><span = class=3D"apple-converted-space"> </span><<a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: underline;">[email protected]</a>><br>Sent: = Wednesday, February 25, 2026 8:07 AM<br>To: Bal=C3=A1zs Varga A <<a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: underline;">[email protected]</a>>; Joel = Halpern <<a href=3D"mailto:[email protected]" style=3D"color: = blue; text-decoration: = underline;">[email protected]</a>><br>Subject: New Version = Notification for draft-varhal-6man-icmp-srv6-vpn-00.txt<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 = repository.<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" style=3D"color: blue; text-decoration: = underline;">https://www.ietf.org/archive/id/draft-varhal-6man-icmp-srv6-vp= n-00.txt</a><br>Status: <a = href=3D"https://datatracker.ietf.org/doc/draft-varhal-6man-icmp-srv6-vpn/"= style=3D"color: blue; text-decoration: = underline;">https://datatracker.ietf.org/doc/draft-varhal-6man-icmp-srv6-v= pn/</a><br>HTMLized:<span class=3D"apple-converted-space"> </span><a = href=3D"https://datatracker.ietf.org/doc/html/draft-varhal-6man-icmp-srv6-= vpn" style=3D"color: blue; text-decoration: = underline;">https://datatracker.ietf.org/doc/html/draft-varhal-6man-icmp-s= rv6-vpn</a><br><br><br>Abstract:<br><br> This document = specifies ICMP error handling in SRv6-based = Virtual<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]" style=3D"color: blue; text-decoration: = underline;">[email protected]</a><br>List Info:<span = class=3D"apple-converted-space"> </span><a = href=3D"https://mailman3.ietf.org/mailman3/lists/[email protected]/" = style=3D"color: blue; text-decoration: = underline;">https://mailman3.ietf.org/mailman3/lists/[email protected]/</a><br= >--------------------------------------------------------------------<o:p>= </o:p></div></div></div></div></div></blockquote></div></div></div></div><= /blockquote></div></div></div></div></blockquote></div></div></blockquote>= </div><div style=3D"margin: 0in; font-size: 12pt; font-family: Aptos, = sans-serif;"><o:p> </o:p></div></div><div style=3D"margin: 0in; = font-size: 12pt; font-family: Aptos, = sans-serif;"><br><br><o:p></o:p></div><pre style=3D"margin: 0in; = font-size: 10pt; font-family: "Courier = New";">--------------------------------------------------------------= ------<o:p></o:p></pre><pre style=3D"margin: 0in; font-size: 10pt; = font-family: "Courier New";">IETF IPv6 working group mailing = list<o:p></o:p></pre><pre style=3D"margin: 0in; font-size: 10pt; = font-family: "Courier New";"><a href=3D"mailto:[email protected]" = style=3D"color: blue; text-decoration: = underline;">[email protected]</a><o:p></o:p></pre><pre style=3D"margin: 0in; = font-size: 10pt; font-family: "Courier New";">List Info: <a = href=3D"https://mailman3.ietf.org/mailman3/lists/[email protected]/" = style=3D"color: blue; text-decoration: = underline;">https://mailman3.ietf.org/mailman3/lists/[email protected]/</a><o:= p></o:p></pre><pre style=3D"margin: 0in; font-size: 10pt; font-family: = "Courier = New";">--------------------------------------------------------------= ------</pre></blockquote></div></div></blockquote></div></div></div></div>= </blockquote></div><br></div></body></html>= --Apple-Mail=_349E8E57-714A-49C5-AA1D-7738B7DECE4B-- --===============4647338382023828717== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5nIG1h aWxpbmcgbGlzdCAtLSBzcHJpbmdAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp bCB0byBzcHJpbmctbGVhdmVAaWV0Zi5vcmcK --===============4647338382023828717==--