[spring] Re: New Version Notification for draft-varhal-6man- icmp-srv6-vpn-01.txt
Krzysztof Szarkowicz <[email protected]> Wed, 15 Apr 2026 13:14:44 +0200
| Newsgroups | gmane.ietf.spring,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <[email protected]> |
--===============8556905784418036394== Content-Type: multipart/alternative; boundary="Apple-Mail=_55C09A6E-4100-4B9C-A849-BC771041E350" --Apple-Mail=_55C09A6E-4100-4B9C-A849-BC771041E350 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bal=C3=A1zs, Thank you for your comments. Please see my responses inline. Cheers, Krzysztof > On 2026 Apr 2, at 17:06, Bal=C3=A1zs Varga A = <[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. [Krzysztof] Indeed. Hence, authors of = draft-ali-6man-srv6-vpn-icmp-error-handling proposed a solution to solve = this (among many others) use case. > 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). [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. > 3. Handling migration/interop (MPLS <-> SRv6) scenarios: > Please clarify by describing the scenario details You are referring = to. Many thanks. [Krzysztof] For example, Mo6 = (draft-ietf-spring-srv6-mpls-interworking-02, Section 7.1.1.2). Topology = diagram from the draft: +-----+ +-----+ 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----------><-----------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> 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. > 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. [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. So, no description about deployments using DX4/DX6. Draft addresses only = deployments using DT4/DT6/DT46. > 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. [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. 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. > 6. Routable VPN-specific SID + multi-domain scenario: > Multi-domain has its side-effects. See reply regarding item 1). [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. > 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]> --Apple-Mail=_55C09A6E-4100-4B9C-A849-BC771041E350 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>Thank you for your = comments. Please see my responses = 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 Apr 2, at 17:06, 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 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><d= iv 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;">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;">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;">[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;">[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;">[email protected]</a>>; IPv6 List <<a = href=3D"mailto:[email protected]" style=3D"color: blue; text-decoration: = underline;">[email protected]</a>>; Mustapha Aissaoui (Nokia) <<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: [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;">[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><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;">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;">[email protected]</a>><br><b>D= ate:<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;">[email protected]</a>>, IPv6 List <<a = href=3D"mailto:[email protected]" style=3D"color: blue; text-decoration: = underline;">[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;">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;">[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: = 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;">[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-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;">https://www.ietf.org/archive/id/draft-varhal-6man-icmp-srv6-vp= n-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;">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>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;">https://author-tools.ietf.org/iddiff?url2=3Ddraft-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;">[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;">[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;">[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;">[email protected]</a></div></div></blockquote></div></div>= </blockquote></div><br></div></body></html>= --Apple-Mail=_55C09A6E-4100-4B9C-A849-BC771041E350-- --===============8556905784418036394== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5nIG1h aWxpbmcgbGlzdCAtLSBzcHJpbmdAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp bCB0byBzcHJpbmctbGVhdmVAaWV0Zi5vcmcK --===============8556905784418036394==--