[spring] Re: [IPv6]Re: New Version Notification for dr aft-varhal-6man-icmp-srv6-vpn-01.txt
Krzysztof Szarkowicz <[email protected]> Tue, 28 Apr 2026 17:22:35 +0200
| Newsgroups | gmane.ietf.spring,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <[email protected]> |
--===============9216904449562573727== Content-Type: multipart/alternative; boundary="Apple-Mail=_527735AE-5150-487E-8E9D-189C7E8FF3FA" --Apple-Mail=_527735AE-5150-487E-8E9D-189C7E8FF3FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Joel, There are many differences between two approaches, one of them is the = difference you mentioned. The authors of = draft-ali-6man-srv6-vpn-icmp-error-handling, before deciding, which = solution to document, evaluated different requirements, like: * work in complex VPN scenarios, like Hub-and-Spoke VPN, CsC, etc. (not = only in basic VPN) * work with per-VRF SIDs (End.DT4/End.DT6/End.DT46), as well as with = per-CE SIDs (End.DX4/End.DX6) * work in different Inter-AS options (Option A, Option B, Option C) * work with multiple encaps, with some encaps pushed on transit routers = (i.e., B-SID expansion) * work in various MPLS/SRv6 interwork/migration scenarios * provide real IPv6 and/or real IPv4 address (if exist) of transit = router to IPv4 traceroute initiator * provide indication in traceroute where the transit path is broken (if = it is broken) And, after evaluation, authors of = draft-ali-6man-srv6-vpn-icmp-error-handling came to the conclusion, = there is no solution that could fulfill all the requirements. Therefore, = authors of draft-ali-6man-srv6-vpn-icmp-error-handling opted for the = solution that has less caveats/limitations, and documented this solution = in draft-ali-6man-srv6-vpn-icmp-error-handling. It is true, that = solution documented in draft-ali-6man-srv6-vpn-icmp-error-handling, = while fulfilling most of the points above, doesn=E2=80=99t fulfill the = last bullet point above. However, where path is broken, while with = solution for overlay traceroute described in = draft-ali-6man-srv6-vpn-icmp-error-handling cannot be solved, it can be = solved using underlay traceroute initiated at PE, so there is still = workaround for that. My impression is, authors of draft-varhal-6man-icmp-srv6-vpn = concentrated on the last bullet point from above list, but didn=E2=80=99t = made through evaluation, how the solution can address other use cases. Thank you, Krzysztof > On 2026 Apr 15, at 16:23, Joel Halpern <[email protected]> wrote: >=20 > Without getting into the details, let me ask about what I see as one = important difference in the two approaches. >=20 > What happens when the path from the ingress to the egress is broken = somewhere along the way. With draft-ali, that seems to mean that all = probes of the path fail. Traceroute will always associate the failrue = with the ingress. Our intention with draft-varhal is that the probes = will succeed along the path until they reach the failure. Thus giving = the operator and the customer (when the operator is willing to expose = these details) better visibility. >=20 > Is there some way that I am missing that draft-ali allows one to = determine where a path failure is occurring? >=20 > Thank you, >=20 > Joel >=20 > On 4/15/2026 7:14 AM, Krzysztof Szarkowicz wrote: >> Hi Bal=C3=A1zs, >>=20 >>=20 >> Thank you for your comments. Please see my responses inline. >>=20 >>=20 >> Cheers, >> Krzysztof >>=20 >>=20 >>> On 2026 Apr 2, at 17:06, Bal=C3=A1zs Varga A = <[email protected]> <mailto:[email protected]> = wrote: >>>=20 >>> Hi Krzysztof, >>> =20 >>> many thanks for the review of the updated draft. Reaction as = follows: >>> =20 >>> 1, Multiple IP encapsulation (e.g., B-SID): >>> I do not think this is an VPN-specific issue. It is a more general = one. >>> Let's assume such a network (B-SID used between P2/P3/P4): >>> =20 >>> A--PE1--P1--P2=3D=3DP3=3D=3DP4--P5--PE2--B >>> =20 >>> If You are tracerouting PE2 from PE1 and Your HL expire at P3, as = per current >>> RFCs, the ICMP error is sent to P2 and PE1 will not receive the ICMP = error >>> message. The multiple encapsulation part of the path is not visible = for the >>> traceroute. >>> Note, that there are no VPNs in the above example. The issue is not = VPN specific, >>> but VPN traceroute also suffers from this unwanted characteristics. >>> =20 >>> I think we agree that here we need a solution, but I would not = expect from a >>> VPN specific solution to solve it. We need a more general one. >>=20 >> [Krzysztof] Indeed. Hence, authors of = draft-ali-6man-srv6-vpn-icmp-error-handling proposed a solution to solve = this (among many others) use case. >>=20 >>> 2, Real IPv4 address of 'P' node: >>> This is covered in the draft. Please, double check the last = paragraph in >>> section 3.4. It is also part of the illustration in Section 3.5 (see = the last >>> PE1_out packet at the end of the section). >>=20 >> [Krzysztof] I see in the draft: =E2=80=9CHow the PE node is aware of = that information is out-of-scope in this document.=E2=80=9D = draft-ali-6man-srv6-vpn-icmp-error-handling, on the other hand, covers = that use case as well. >>=20 >>=20 >>> 3. Handling migration/interop (MPLS <-> SRv6) scenarios: >>> Please clarify by describing the scenario details You are referring = to. Many thanks. >>=20 >> [Krzysztof] For example, Mo6 = (draft-ietf-spring-srv6-mpls-interworking-02, Section 7.1.1.2). Topology = diagram from the draft: >>=20 >> +-----+ +-----+ RD:V/v via 10 +-----+ >> .......|S-RR1|<...............|S-RR2|<.................|S-RR3| <.. >> : +-----+ +-----+ +-----+ : >> : : >> : : >> = +--:-------------------+----------------------+---------------------:-+ >> | : | 2 | | | 5 | | | 8 | : = | >> | : +---+ | +---+ | +---+ : = | >> | : | | : = | >> | : | | : = | >> | : | | : = | >> |----+ IGP1 +---+ IGP2 +---+ IGP3 = +----| >> | 1 | | 4 | | 7 | | 10 = | >> |----+ +---+ +---+ = +----| >> | | | = | >> | | | = | >> | | | = | >> | +---+ | +---+ | +---+ = | >> | | 3 | | | 6 | | | 9 | = | >> = +----------------------+----------------------+-----------------------+ >> iPE iBR eBR = ePE >>=20 >> = <----------LI---------><----------C----------><-----------LE----------> >> Figure 1 = <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interwo= rking-02#figure-1>: Reference multi-domain network topology = <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interwo= rking-02#name-reference-multi-domain-netw> >>=20 >> In Mo6, IGP1 and IGP3 are MPLS domains, whereas IGP2 is SRv6 domain. = Assume, TTL/HC expires in IGP2 (SRv6 domain) at some transit node = between node =E2=80=984=E2=80=99 and node =E2=80=987=E2=80=99. >>=20 >>> 4. Handling VPNs with DX4/DX6 SIDs: >>> This is covered in the draft. Please, double check Section 3.2. The = paragraph after >>> the "Packet processing" steps clarifies it in detail. >>=20 >> [Krzysztof] I see following in the draft: >> More specifically for a VPN service the PE node can allocate SID(s) = per-prefix (e.g., End.DX6) or per-vrf (e.g., End.DT6). The solution uses = a per-vrf SID (e.g., End.DT6) in the IP SA of the SRv6 encapsulated = packets. >>=20 >> So, no description about deployments using DX4/DX6. Draft addresses = only deployments using DT4/DT6/DT46. >>=20 >>> 5. Handling of Hub-and-Spoke VRFs: >>> This is covered in the draft. Please, double check Section 3.2. The = second paragraph >>> after the "Packet processing" steps clarifies it in detail. >>=20 >> [Krzysztof] in the draft I see: >> For more sophisticated VPN configurations (e.g., Hub-and-Spoke VPN) = where multiple VRFs (and SIDs) are configured for a given VPN, the VPN = specific SID of PE1 always refers to the VRF instance (and its per-vrf = SID) where the prefixes of the connected customer site(s) can be looked = up. >>=20 >> Draft assumes per-VRF SID, while many hub-and-spoke deployments use = per-CE SID, to prevent IP lookup inside spoke VRF and thus to prevent = unintentional direct CE-to-CE communication inside spoke VRF. >>=20 >>> 6. Routable VPN-specific SID + multi-domain scenario: >>> Multi-domain has its side-effects. See reply regarding item 1). >>=20 >> [Krzysztof] Indeed. The authors of = draft-ali-6man-srv6-vpn-icmp-error-handling realized that, and proposed = solution in the draft-ali-6man-srv6-vpn-icmp-error-handling to address = this. >>=20 >>> 7. Different visibility for served VPNs >>> Yes, this section needs some further clarification. It is an = additional (optional) >>> capability of the VPN-associated-ICMP-process-function. We will = update for the >>> next version. >>> =20 >>> Thanks & Cheers >>> Bala'zs >>> =20 >>> =20 >>> =20 >>> From: Krzysztof Szarkowicz <[email protected] = <mailto:[email protected]>> >>> Sent: Monday, March 30, 2026 10:01 AM >>> To: Bal=C3=A1zs Varga A <[email protected] = <mailto:[email protected]>> >>> Cc: SPRING WG List <[email protected] <mailto:[email protected]>>; IPv6 = List <[email protected] <mailto:[email protected]>>; Mustapha Aissaoui (Nokia) = <[email protected] <mailto:[email protected]>> >>> Subject: Re: [spring] New Version Notification for = draft-varhal-6man-icmp-srv6-vpn-01.txt >>> =20 >>> Hi Bal=C3=A1zs, >>> =20 >>> =20 >>> I have checked the updated version of the draft. It addresses some = shortcomings of this solution raised for initial version of the draft, = but is still doesn't address many other shortcomings: >>> =20 >>> =20 >>> 1. Handling of multiple IP encapsulations (e.g. expanding of B-SID = with encap mode) on the node that is not service aware - i.e., B-SID is = expanded on a node without VRF, and with no service prefix visibility) >>> =20 >>> 2. Providing real IPv4 address of 'P' node (when such address exists = - for example during migration scenarios, when dual IPv4/IPv6 stack is = used) to the node invoking IPv4 traceroute >>> =20 >>> 3. Handling migration/interop (MPLS <-> SRv6) scenarios >>> =20 >>> 4. Handling VPNs with DX4/DX6 SIDs, where DT4/DT6/DT46 SIDs are not = deployed >>> =20 >>> 5. Handling of Hub-and-Spoke VRFs, where on PE traffic incoming on = PE-CE interfaces in multiple local VRFs, is forced (vendor terminology: = filter based forwarding, policy based routing, etc.) via single outgoing = VRF (VRF-out) >>> =20 >>> 6. "As the locator part of the VPN-specific SID is routable within = the SRv6 domain other PE and P nodes of the SRv6 domain can send/route = packets to it." -> this is not necessarily true in multi-domain designs, = with B-SID expansion at domain boundaries. >>> =20 >>> 7. "It can hide the SIDs used inside the SRv6 domain and can provide = different visibility for served VPNs if needed." -> Not sure, if I = understand this statement >>> =20 >>> =20 >>> Cheers, >>> Krzysztof >>> =20 >>>=20 >>>=20 >>> On 2026 Mar 18, at 22:30, Mustapha Aissaoui (Nokia) = <[email protected] = <mailto:[email protected]>> wrote: >>> =20 >>> Hi Balazs, >>> I have a couple of comments on this draft.=20 >>> =20 >>> The first one is to reference RFC 2473 = <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc2473*= section-8__;Iw!!NEt6yMaO-gk!CQq_FdKjC1gmIXsGJG4jQ7N1Vqiian8wAqFRv79hihx0kc= rkd9DMQMiDKTMEWmjTVjCAp5ToOHpDhefmyEnrsOAOGLTzd08$> as it is well = described that an ICMP reply must be sent on the outer IPv6 header in = the case of an IP-in-IP tunnel. For me this is the closest prior art we = can refer to when discussing potential new solutions, other than ICMP = tunneling.=20 >>> =20 >>> This RFC also describes a general ICMP relay function covering = various ICMP error messages. In the specific context of a TCP/UDP = traceroute probe, this relay function will only work for traceroute = packets of routes in the global routing table as discussed in an earlier = thread on draft-ali-6man-srv6-vpn-icmp-error-handling. It does however = not address probes sent in VRF context. >>> =20 >>> The second is regarding the use of a SRv6 service SID as the source = address on the outer IPv6 header. The source address in the outer IPv6 = header is used by downstream routers to report various ICMP error = messages on the SRv6 tunnel, some of which are ad-hoc and triggered by = malformed outer headers in user packets. Hence it cannot be sent to a = specific VRF context of the ingress SRv6 PE.=20 >>> =20 >>> I can see a service SID being used as the source address of the = traceroute for probes originating at the ingress SRv6 PE since the user = can configure this specifically for these probes. But not for probes = generated by the CE since they are treated as user packets at the = ingress SRv6 PE and they would inherit the source address of the SRv6 = tunnel. For probes originating at the ingress SRv6 PE, one can correlate = the error message with a specific VPN or global routing table traceroute = probe based on TCP or UDP port number. So there are alternatives too. >>> =20 >>> Regards, >>> Mustapha. >>> =20 >>> From: Bal=C3=A1zs Varga A = <[email protected] = <mailto:[email protected]>> >>> Date: Monday, March 16, 2026 at 9:51=E2=80=AFAM >>> To: SPRING WG List <[email protected] <mailto:[email protected]>>, IPv6 = List <[email protected] <mailto:[email protected]>> >>> Subject: [spring] FW: New Version Notification for = draft-varhal-6man-icmp-srv6-vpn-01.txt >>>=20 >>>=20 >>> CAUTION: This is an external email. Please be very careful when = clicking links or opening attachments. See the URL nok.it/ext = <http://nok.it/ext> for additional information. >>>=20 >>>=20 >>>=20 >>> Hi, >>>=20 >>> Based on the valuable feedbacks on the lists the draft on >>> "ICMP Error Handling for VPNs in SRv6 Networks" was >>> updated. >>>=20 >>> Thanks & Cheers >>> Bala'zs (and Joel) >>>=20 >>> -----Original Message----- >>> From: [email protected] <mailto:[email protected]> = <[email protected] <mailto:[email protected]>> >>> Sent: Monday, March 16, 2026 2:36 PM >>> 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-01.txt >>>=20 >>> A new version of Internet-Draft = draft-varhal-6man-icmp-srv6-vpn-01.txt has been successfully submitted = by Balazs Varga and posted to the IETF repository. >>>=20 >>> Name: draft-varhal-6man-icmp-srv6-vpn >>> Revision: 01 >>> Title: ICMP Error Handling for VPNs in SRv6 Networks >>> Date: 2026-03-16 >>> Group: Individual Submission >>> Pages: 12 >>> URL: = https://www.ietf.org/archive/id/draft-varhal-6man-icmp-srv6-vpn-01.txt >>> Status: = https://datatracker.ietf.org/doc/draft-varhal-6man-icmp-srv6-vpn/ >>> HTMLized: = https://datatracker.ietf.org/doc/html/draft-varhal-6man-icmp-srv6-vpn >>> Diff: = https://author-tools.ietf.org/iddiff?url2=3Ddraft-varhal-6man-icmp-srv6-vp= n-01 >>>=20 >>> Abstract: >>>=20 >>> This document specifies ICMP error handling in SRv6-based Virtual >>> Private Networks, that support direct localization of failures. = It >>> provides a solution for connectivity check and fault localization >>> without adding complexity to P nodes and keeps P nodes service >>> agnostic. ICMP processing is changed only on ingress PE nodes = and >>> gains from adding VPN-specific information to the SRv6 = encapsulated >>> packet. Egress PE nodes are not involved in the forwarding of = the >>> ICMP error messages. Therefore, the solution provides visibility >>> upto the failure even if ingress PE to egress PE connectivity is >>> broken within the SR domain. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>> _______________________________________________ >>> spring mailing list -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] = <mailto:[email protected]> >>> _______________________________________________ >>> spring mailing list -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] = <mailto:[email protected]> >>=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=_527735AE-5150-487E-8E9D-189C7E8FF3FA 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;">Joel,<div><br></div><div>There are many = differences between two approaches, one of them is the difference you = mentioned. The authors = of draft-ali-6man-srv6-vpn-icmp-error-handling, before deciding, = which solution to document, evaluated different requirements, = like:</div><div><br></div><div>* work in complex VPN scenarios, like = Hub-and-Spoke VPN, CsC, etc. (not only in basic VPN)</div><div>* work = with per-VRF SIDs (End.DT4/End.DT6/End.DT46), as well as with per-CE = SIDs (End.DX4/End.DX6)</div><div>* work in different Inter-AS options = (Option A, Option B, Option C)</div><div>* work with multiple encaps, = with some encaps pushed on transit routers (i.e., B-SID = expansion)</div><div>* work in various MPLS/SRv6 interwork/migration = scenarios</div><div>* provide real IPv6 and/or real IPv4 address (if = exist) of transit router to IPv4 traceroute initiator</div><div>* = provide indication in traceroute where the transit path is broken (if it = is broken)</div><div><br></div><div>And, after evaluation, authors of = draft-ali-6man-srv6-vpn-icmp-error-handling came to the conclusion, = there is no solution that could fulfill all the requirements. Therefore, = authors of draft-ali-6man-srv6-vpn-icmp-error-handling opted for the = solution that has less caveats/limitations, and documented this solution = in draft-ali-6man-srv6-vpn-icmp-error-handling. It is true, that = solution documented in draft-ali-6man-srv6-vpn-icmp-error-handling, = while fulfilling most of the points above, doesn=E2=80=99t fulfill the = last bullet point above. However, where path is broken, while with = solution for overlay traceroute described in = draft-ali-6man-srv6-vpn-icmp-error-handling cannot be solved, it can be = solved using underlay traceroute initiated at PE, so there is still = workaround for that.</div><div><br></div><div>My impression is, authors = of draft-varhal-6man-icmp-srv6-vpn concentrated on the last bullet = point from above list, but didn=E2=80=99t made through evaluation, how = the solution can address other use cases.</div><div><br></div><div>Thank = you,</div><div>Krzysztof</div><div><br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On 2026 Apr 15, at 16:23, Joel Halpern = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div> =20 <meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3DUTF-8"> =20 <div><p>Without getting into the details, let me ask about what I see = as one important difference in the two approaches.</p><p>What happens = when the path from the ingress to the egress is broken somewhere along the way. With draft-ali, that seems = to mean that all probes of the path fail. Traceroute will = always associate the failrue with the ingress. Our intention with draft-varhal is that the probes will succeed along the path until they reach the failure. Thus giving the operator and the = customer (when the operator is willing to expose these details) better visibility.</p><p>Is there some way that I am missing that = draft-ali allows one to determine where a path failure is occurring?</p><p>Thank = you,</p><p>Joel</p> <div class=3D"moz-cite-prefix">On 4/15/2026 7:14 AM, Krzysztof Szarkowicz wrote:<br> </div> <blockquote type=3D"cite" = cite=3D"mid:[email protected]"> <meta http-equiv=3D"content-type" content=3D"text/html; = charset=3DUTF-8"> Hi Bal=C3=A1zs, <div><br> </div> <div><br> </div> <div>Thank you for your comments. Please see my responses = inline.</div> <div><br> </div> <div><br> </div> <div>Cheers,</div> <div>Krzysztof</div> <div><br id=3D"lineBreakAtBeginningOfMessage"> <div><br> <blockquote type=3D"cite"> <div>On 2026 Apr 2, at 17:06, Bal=C3=A1zs Varga A <a class=3D"moz-txt-link-rfc2396E" = href=3D"mailto:[email protected]"><[email protected]= m></a> 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 the review of the updated draft. Reaction as follows:<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;">1, Multiple IP encapsulation (e.g., = B-SID):<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">I do not think this is an VPN-specific issue. It is a more general one.<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">Let's assume such a network (B-SID used between = P2/P3/P4):<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;">A--PE1--P1--P2=3D=3DP3=3D=3DP4--P5--PE2--B<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;">If You are tracerouting PE2 from PE1 and Your HL expire at P3, as per current<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">RFCs, the ICMP error is sent to P2 and PE1 will not receive the ICMP error<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">message. The multiple encapsulation part of the path is not visible for the<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">traceroute.<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">Note, that there are no VPNs in the above example. The issue is not VPN specific,<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">but VPN traceroute also suffers from this unwanted characteristics.<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 agree that here we need a solution, but I would not expect from a<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">VPN specific solution to solve it. We need a more general one.</div> </div> </div> </blockquote> <div><br> </div> <div>[Krzysztof] Indeed. Hence, authors of draft-ali-6man-srv6-vpn-icmp-error-handling proposed a solution to solve this (among many others) use case.</div> <br> <blockquote type=3D"cite"> <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;">2, Real IPv4 address of 'P' node:<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">This is covered in the draft. Please, double check the last paragraph in<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">section 3.4. It is also part of the illustration in Section 3.5 (see the last<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">PE1_out packet at the end of the section).</div> </div> </blockquote> <div><br> </div> <div>[Krzysztof] I see in the draft: =E2=80=9CHow the PE node = is aware of that information is out-of-scope in this document.=E2=80=9D= draft-ali-6man-srv6-vpn-icmp-error-handling, on the other hand, covers that use case as well.</div> <div><br> </div> <br> <blockquote type=3D"cite"> <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;">3. Handling migration/interop (MPLS <-> SRv6) scenarios:<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">Please clarify by describing the scenario details You are referring to. Many thanks.</div> </div> </blockquote> <div><br> </div> <div>[Krzysztof] For example, Mo6 (draft-ietf-spring-srv6-mpls-interworking-02, Section 7.1.1.2). Topology diagram from the draft:</div> <div><br> </div> <div> <div class=3D"alignLeft art-text artwork" id=3D"section-2-2.1"= style=3D"font-size: 16px; box-sizing: border-box; margin-top: 20.8px; = margin-bottom: 20.8px; flex-wrap: nowrap; align-items: end; display: = flex; color: rgb(32, 37, 42); font-family: "Noto Sans Mono", = SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", = "Courier New", monospace; font-variant-ligatures: normal; = background-color: rgb(255, 255, 255);"> <pre style=3D"box-sizing: border-box; font-family: = "Noto Sans Mono", SFMono-Regular, Menlo, Monaco, Consolas, = "Liberation Mono", "Courier New", monospace; = font-size: 1em; margin: 0px; overflow: auto clip; padding: 0px; flex: 0 = 0 content; max-width: 72ch;"> +-----+ +-----+ = RD:V/v via 10 +-----+ .......|S-RR1|<...............|S-RR2|<.................|S-RR3| = <.. : +-----+ +-----+ +-----+ : : : : : +--:-------------------+----------------------+---------------------:-+ | : | 2 | | | 5 | | | 8 | : | | : +---+ | +---+ | +---+ : | | : | | : | | : | | : | | : | | : | |----+ IGP1 +---+ IGP2 +---+ IGP3 +----| | 1 | | 4 | | 7 | | 10 | |----+ +---+ +---+ +----| | | | | | | | | | | | | | +---+ | +---+ | +---+ | | | 3 | | | 6 | | | 9 | | +----------------------+----------------------+-----------------------+ iPE iBR eBR ePE = <----------LI---------><----------C----------><-----------L= E----------> </pre> </div> <figcaption style=3D"font-size: 16px; box-sizing: = border-box; text-align: center; margin-top: 20.8px; color: rgb(32, 37, = 42); font-family: "Noto Sans Mono", SFMono-Regular, Menlo, = Monaco, Consolas, "Liberation Mono", "Courier New", = monospace; font-variant-ligatures: normal; background-color: rgb(255, = 255, 255);"><a = href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-= interworking-02#figure-1" class=3D"selfRef" style=3D"box-sizing: = border-box; color: inherit; text-decoration: none;" = moz-do-not-send=3D"true">Figure 1</a>: <a = href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-= interworking-02#name-reference-multi-domain-netw" class=3D"selfRef" = style=3D"box-sizing: border-box; color: inherit; text-decoration: none;" = moz-do-not-send=3D"true">Reference multi-domain network topology</a></figcaption></div> <div><br> </div> <div>In Mo6, IGP1 and IGP3 are MPLS domains, whereas IGP2 is SRv6 domain. Assume, TTL/HC expires in IGP2 (SRv6 domain) at some transit node between node =E2=80=984=E2=80=99 and node = =E2=80=987=E2=80=99.</div> <br> <blockquote type=3D"cite"> <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;">4. Handling VPNs with DX4/DX6 SIDs:<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">This is covered in the draft. Please, double check Section 3.2. The paragraph after<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">the "Packet processing" steps clarifies it in detail.</div> </div> </blockquote> <div><br> </div> [Krzysztof] I see following in the draft:</div> <div><p id=3D"section-3.2-5" style=3D"font-size: 16px; = box-sizing: border-box; margin: 20.8px 0px 20.8px 3ch; overflow-wrap: = break-word; color: rgb(32, 37, 42); font-family: "Noto Sans = Mono", SFMono-Regular, Menlo, Monaco, Consolas, "Liberation = Mono", "Courier New", monospace; font-variant-ligatures: = normal; background-color: rgb(255, 255, 255);">More specifically for a VPN service the PE node can allocate SID(s) per-prefix (e.g., End.DX6) or per-vrf (e.g., End.DT6). The solution uses a per-vrf SID (e.g., End.DT6) in the IP SA of the SRv6 encapsulated packets.</p> </div> <div>So, no description about deployments using DX4/DX6. Draft addresses only deployments using DT4/DT6/DT46.</div> <div><br> <blockquote type=3D"cite"> <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;">5. Handling of Hub-and-Spoke VRFs:<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">This is covered in the draft. Please, double check Section 3.2. The second paragraph<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">after the "Packet processing" steps clarifies it in = detail.</div> </div> </blockquote> <div><br> </div> <div>[Krzysztof] in the draft I see:</div> <div><p id=3D"section-3.2-6" style=3D"font-size: 16px; = box-sizing: border-box; margin: 20.8px 0px 20.8px 3ch; overflow-wrap: = break-word; color: rgb(32, 37, 42); font-family: "Noto Sans = Mono", SFMono-Regular, Menlo, Monaco, Consolas, "Liberation = Mono", "Courier New", monospace; font-variant-ligatures: = normal; background-color: rgb(255, 255, 255);">For more sophisticated VPN configurations (e.g., Hub-and-Spoke VPN) where multiple VRFs (and SIDs) are configured for a given VPN, the VPN specific SID of PE1 always refers to the VRF instance (and its per-vrf SID) where the prefixes of the connected customer site(s) can be looked up.</p> </div> <div>Draft assumes per-VRF SID, while many hub-and-spoke deployments use per-CE SID, to prevent IP lookup inside spoke VRF and thus to prevent unintentional direct CE-to-CE communication inside spoke VRF.</div> <br> <blockquote type=3D"cite"> <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;">6. Routable VPN-specific SID + multi-domain = scenario:<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">Multi-domain has its side-effects. See reply regarding item 1).</div> </div> </blockquote> <div><br> </div> <div>[Krzysztof] Indeed. The authors of draft-ali-6man-srv6-vpn-icmp-error-handling realized that, and proposed solution in the draft-ali-6man-srv6-vpn-icmp-error-handling to address = this.</div> <br> <blockquote type=3D"cite"> <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;">7. Different visibility for served VPNs<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">Yes, this section needs some further clarification. It is an additional (optional)<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">capability of the VPN-associated-ICMP-process-function. We will update for the<o:p></o:p></div> <div style=3D"margin: 0in; font-size: 12pt; font-family: = Aptos, sans-serif;">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;">Thanks & 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 <<a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: underline;" moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a>><br> <b>Sent:</b><span = class=3D"Apple-converted-space"> </span>Monday, March 30, 2026 10:01 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;" moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a>><br> <b>Cc:</b><span = class=3D"Apple-converted-space"> </span>SPRING WG List <<a href=3D"mailto:[email protected]" = style=3D"color: blue; text-decoration: underline;" = moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a>>; IPv6 List <<a href=3D"mailto:[email protected]" = style=3D"color: blue; text-decoration: underline;" = moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a>>; Mustapha Aissaoui (Nokia) <<a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: underline;" moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a>><br> <b>Subject:</b><span = class=3D"Apple-converted-space"> </span>Re: [spring] New Version Notification for = draft-varhal-6man-icmp-srv6-vpn-01.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> <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 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;">I have checked the updated version of the draft. It addresses some shortcomings of this solution raised for initial version of the draft, but is still doesn't address many other shortcomings:<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;">1. Handling of multiple IP encapsulations (e.g. expanding of B-SID with encap mode) on the node that is not service aware - i.e., B-SID is expanded on a node without VRF, and with no service prefix = visibility)<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;">2. Providing real IPv4 address of 'P' node (when such address exists - for example during migration scenarios, when dual IPv4/IPv6 stack is used) to the node invoking IPv4 traceroute<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;">3. Handling migration/interop (MPLS <-> SRv6) scenarios<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;">4. Handling VPNs with DX4/DX6 SIDs, where DT4/DT6/DT46 SIDs are not deployed<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;">5. Handling of Hub-and-Spoke VRFs, where on PE traffic incoming on PE-CE interfaces in multiple local VRFs, is forced (vendor terminology: filter based forwarding, policy based routing, etc.) via single outgoing VRF (VRF-out)<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;">6. "As the locator part of the VPN-specific SID is routable within the SRv6 domain other PE and P nodes of the SRv6 domain can send/route packets to it." -> this is not necessarily true in multi-domain designs, with B-SID expansion at domain = boundaries.<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;">7. "It can hide the SIDs used inside the SRv6 domain and can provide different visibility for served VPNs if needed." -> Not sure, if I understand this statement<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> <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;"><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 18, at 22:30, Mustapha Aissaoui (Nokia) <<a = href=3D"mailto:[email protected]" = style=3D"color: blue; text-decoration: underline;" = moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]= .org</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> <div> <div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">Hi Balazs,<o:p></o:p></div> </div> <div> <div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">I have a couple of comments on this = 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> <div> <div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">The first one is to reference<span = class=3D"Apple-converted-space"> </span><a = href=3D"https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/r= fc2473*section-8__;Iw!!NEt6yMaO-gk!CQq_FdKjC1gmIXsGJG4jQ7N1Vqiian8wAqFRv79= hihx0kcrkd9DMQMiDKTMEWmjTVjCAp5ToOHpDhefmyEnrsOAOGLTzd08$" style=3D"color:= blue; text-decoration: underline;" moz-do-not-send=3D"true">RFC 2473</a> as it is well described that = an ICMP reply must be sent on the outer IPv6 header in the case of an IP-in-IP tunnel. For me this is the closest prior art we can refer to when discussing potential new solutions, other than ICMP = tunneling. <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 RFC also describes a general ICMP relay function covering various ICMP error messages. In the specific context of a TCP/UDP traceroute probe, this relay function will only work for traceroute packets of routes in the global routing table as discussed in an earlier thread on draft-ali-6man-srv6-vpn-icmp-error-handling. It does however not address probes sent in VRF context.<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 second is regarding the use of a SRv6 service SID as the source address on the outer IPv6 header. The source address in the outer IPv6 header is used by downstream routers to report various ICMP error messages on the SRv6 tunnel, some of which are ad-hoc and triggered by malformed outer headers in user packets. Hence it cannot be sent to a specific VRF context of the ingress SRv6 = PE. <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;">I can see a service SID being used as the source address of the traceroute for probes originating at the ingress SRv6 PE since the user can configure this specifically for these probes. But not for probes generated by the CE since they are treated as user packets at the ingress SRv6 PE and they would inherit the source address of the SRv6 tunnel. For probes originating at the ingress SRv6 PE, one can correlate the error message with a specific VPN or global routing table traceroute probe based on TCP or UDP port number. So there are alternatives too.<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;">Regards,<o:p></o:p></div> </div> <div> <div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;">Mustapha.<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 id=3D"mail-editor-reference-message-container">= <div style=3D"border-width: 1pt medium medium; = border-style: solid none none; border-image: none; padding: 3pt 0in 0in; = border-color: currentcolor;"><p class=3D"MsoNormal" style=3D"margin: 0in = 0in 12pt; font-size: 12pt; font-family: Aptos, = sans-serif;"><b>From:<span = class=3D"Apple-converted-space"> </span></b>Bal=C3=A1zs Varga A <<a = href=3D"mailto:[email protected]" = style=3D"color: blue; text-decoration: underline;" = moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]= .org</a>><br> <b>Date:<span = class=3D"Apple-converted-space"> </span></b>Monday, March 16, 2026 at 9:51<span = style=3D"font-family: Arial, sans-serif;">=E2=80=AF</span>AM<br> <b>To:<span = class=3D"Apple-converted-space"> </span></b>SPRING WG List <<a href=3D"mailto:[email protected]"= style=3D"color: blue; text-decoration: underline;" = moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a>>, IPv6 List <<a href=3D"mailto:[email protected]"= style=3D"color: blue; text-decoration: underline;" = moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a>><br> <b>Subject:<span = class=3D"Apple-converted-space"> </span></b>[spring] FW: New Version Notification for = draft-varhal-6man-icmp-srv6-vpn-01.txt<o:p></o:p></p> </div> <div> <div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, sans-serif;"><span style=3D"font-size: 11pt;"><br> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL<span = class=3D"Apple-converted-space"> </span><a href=3D"http://nok.it/ext"= style=3D"color: blue; text-decoration: underline;" = moz-do-not-send=3D"true">nok.it/ext</a><span = class=3D"Apple-converted-space"> </span>for additional information.<br> <br> <br> <br> Hi,<br> <br> Based on the valuable feedbacks on the lists the draft on<br> "ICMP Error Handling for VPNs in SRv6 Networks" was<br> updated.<br> <br> Thanks & Cheers<br> Bala'zs (and Joel)<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;" moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a><span = class=3D"Apple-converted-space"> </span><<a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: underline;" moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a>><br> Sent: Monday, March 16, 2026 2:36 PM<br> To: Bal=C3=A1zs Varga A <<a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: underline;" moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a>>; Joel Halpern <<a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: underline;" moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a>><br> Subject: New Version Notification for draft-varhal-6man-icmp-srv6-vpn-01.txt<br> <br> A new version of Internet-Draft draft-varhal-6man-icmp-srv6-vpn-01.txt has been successfully submitted by Balazs Varga and posted to the IETF = repository.<br> <br> Name: = draft-varhal-6man-icmp-srv6-vpn<br> Revision: 01<br> Title: ICMP Error = Handling for VPNs in SRv6 Networks<br> Date: = 2026-03-16<br> Group: Individual = Submission<br> Pages: 12<br> URL: <span = class=3D"Apple-converted-space"> </span><a = href=3D"https://www.ietf.org/archive/id/draft-varhal-6man-icmp-srv6-vpn-01= .txt" style=3D"color: blue; text-decoration: underline;" = moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">https://www.ietf.org/archive/id/draft-varh= al-6man-icmp-srv6-vpn-01.txt</a><br> Status: <span = class=3D"Apple-converted-space"> </span><a = href=3D"https://datatracker.ietf.org/doc/draft-varhal-6man-icmp-srv6-vpn/"= style=3D"color: blue; text-decoration: underline;" = moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">https://datatracker.ietf.org/doc/draft-var= hal-6man-icmp-srv6-vpn/</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;" = moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">https://datatracker.ietf.org/doc/html/draf= t-varhal-6man-icmp-srv6-vpn</a><br> Diff: <span = class=3D"Apple-converted-space"> </span><a = href=3D"https://author-tools.ietf.org/iddiff?url2=3Ddraft-varhal-6man-icmp= -srv6-vpn-01" style=3D"color: blue; text-decoration: underline;" = moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">https://author-tools.ietf.org/iddiff?url2=3D= draft-varhal-6man-icmp-srv6-vpn-01</a><br> <br> Abstract:<br> <br> This document specifies ICMP = error handling in SRv6-based Virtual<br> Private Networks, that = support direct localization of failures. It<br> provides a solution for = connectivity check and fault localization<br> without adding complexity to = P nodes and keeps P nodes service<br> agnostic. ICMP = processing is changed only on ingress PE nodes and<br> gains from adding = VPN-specific information to the SRv6 encapsulated<br> packet. Egress PE nodes = are not involved in the forwarding of the<br> ICMP error messages. = Therefore, the solution provides visibility<br> upto the failure even if = ingress PE to egress PE connectivity is<br> broken within the SR = domain.<br> <br> <br> <br> The IETF Secretariat<br> <br> <br> _______________________________________________<br> spring mailing list --<span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:[email protected]" style=3D"color: blue; text-decoration: = underline;" moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a><br> To unsubscribe send an email to<span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: underline;" moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a><o:p></o:p></span= ></div> </div> </div> </div> <div style=3D"margin: 0in; font-size: 12pt; = font-family: Aptos, = sans-serif;">_______________________________________________<br> spring mailing list --<span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:[email protected]" style=3D"color: blue; text-decoration: = underline;" moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a><br> To unsubscribe send an email to<span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:[email protected]" style=3D"color: blue; = text-decoration: underline;" moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a></div> </div> </blockquote> </div> </div> </blockquote> </div> <br> </div> <br> <fieldset class=3D"moz-mime-attachment-header"></fieldset> <pre wrap=3D"" = class=3D"moz-quote-pre">--------------------------------------------------= ------------------ IETF IPv6 working group mailing list <a class=3D"moz-txt-link-abbreviated" = href=3D"mailto:[email protected]">[email protected]</a> List Info: <a class=3D"moz-txt-link-freetext" = href=3D"https://mailman3.ietf.org/mailman3/lists/[email protected]/">https://m= ailman3.ietf.org/mailman3/lists/[email protected]/</a> -------------------------------------------------------------------- </pre> </blockquote> </div> </div></blockquote></div><br></div></body></html>= --Apple-Mail=_527735AE-5150-487E-8E9D-189C7E8FF3FA-- --===============9216904449562573727== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5nIG1h aWxpbmcgbGlzdCAtLSBzcHJpbmdAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp bCB0byBzcHJpbmctbGVhdmVAaWV0Zi5vcmcK --===============9216904449562573727==--