[spring] Re: New Version Notification for draft-varhal-6man- icmp-srv6-vpn-01.txt
Krzysztof Szarkowicz <[email protected]> Mon, 30 Mar 2026 10:01:00 +0200
| Newsgroups | gmane.ietf.spring,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <[email protected]> |
--===============4696857408310237559== Content-Type: multipart/alternative; boundary="Apple-Mail=_ED115FBA-F6FA-4912-8E08-D80369723106" --Apple-Mail=_ED115FBA-F6FA-4912-8E08-D80369723106 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bal=C3=A1zs, 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: 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) 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 3. Handling migration/interop (MPLS <-> SRv6) scenarios 4. Handling VPNs with DX4/DX6 SIDs, where DT4/DT6/DT46 SIDs are not = deployed 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) 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. 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 Cheers, Krzysztof > On 2026 Mar 18, at 22:30, Mustapha Aissaoui (Nokia) = <[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]> > Date: Monday, March 16, 2026 at 9:51=E2=80=AFAM > To: SPRING WG List <[email protected]>, IPv6 List <[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 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] <[email protected]> > Sent: Monday, March 16, 2026 2:36 PM > To: Bal=C3=A1zs Varga A <[email protected]>; Joel Halpern = <[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] > To unsubscribe send an email to [email protected] > _______________________________________________ > spring mailing list -- [email protected] > To unsubscribe send an email to [email protected] --Apple-Mail=_ED115FBA-F6FA-4912-8E08-D80369723106 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;"><div>Hi = Bal=C3=A1zs,</div><div><br></div><div><br></div><div>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:</div><div><br></div><div><br></div><div>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)</div><div><br></div><div>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</div><div><br></div><div>3. Handling migration/interop (MPLS = <-> SRv6) scenarios</div><div><br></div><div>4. Handling VPNs with = DX4/DX6 SIDs, where DT4/DT6/DT46 SIDs are not = deployed</div><div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div><br></div><div>Cheers,</div><div>Krzysz= tof</div><div><br></div><div><br><blockquote type=3D"cite"><div>On 2026 = Mar 18, at 22:30, Mustapha Aissaoui (Nokia) = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8"> <div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> Hi Balazs,</div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> I have a couple of comments on this draft. </div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> <br> </div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> The first one is to reference <a = href=3D"https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/r= fc2473*section-8__;Iw!!NEt6yMaO-gk!CQq_FdKjC1gmIXsGJG4jQ7N1Vqiian8wAqFRv79= hihx0kcrkd9DMQMiDKTMEWmjTVjCAp5ToOHpDhefmyEnrsOAOGLTzd08$" = data-outlook-id=3D"29756022-8c31-4344-96cf-cc0fe6233dde"> 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. </div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> <br> </div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> 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.</div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> <br> </div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> 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. </div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> <br> </div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> 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.</div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> <br> </div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> Regards,</div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> Mustapha.</div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, = sans-serif; font-size: 12pt;"> <br> </div> <div id=3D"mail-editor-reference-message-container"> <div class=3D"ms-outlook-mobile-reference-message skipProofing"> <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> </div> <div class=3D"ms-outlook-mobile-reference-message skipProofing" = style=3D"text-align: left; padding: 3pt 0in 0in; border-width: 1pt = medium medium; border-style: solid none none; border-color: rgb(181, = 196, 223) currentcolor currentcolor; font-family: Aptos; font-size: = 12pt;"> <b>From: </b>Bal=C3=A1zs Varga A = <[email protected]><br> <b>Date: </b>Monday, March 16, 2026 at 9:51=E2=80=AFAM<br> <b>To: </b>SPRING WG List <[email protected]>, IPv6 List = <[email protected]><br> <b>Subject: </b>[spring] FW: New Version Notification for = draft-varhal-6man-icmp-srv6-vpn-01.txt<br> <br> </div> <div class=3D"PlainText" 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 nok.it/ext 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: [email protected] <[email protected]><br> Sent: Monday, March 16, 2026 2:36 PM<br> To: Bal=C3=A1zs Varga A <[email protected]>; Joel = Halpern <[email protected]><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: <a = href=3D"https://www.ietf.org/archive/id/draft-varhal-6man-icmp-srv6-vpn-01= .txt" data-outlook-id=3D"8a36b650-8b1a-40d0-a48e-73f33e7204b1"> = https://www.ietf.org/archive/id/draft-varhal-6man-icmp-srv6-vpn-01.txt</a>= <br> Status: <a = href=3D"https://datatracker.ietf.org/doc/draft-varhal-6man-icmp-srv6-vpn/"= data-outlook-id=3D"2cf9c875-7bf1-46d3-959f-6bd0dc81248a"> = https://datatracker.ietf.org/doc/draft-varhal-6man-icmp-srv6-vpn/</a><br> HTMLized: <a = href=3D"https://datatracker.ietf.org/doc/html/draft-varhal-6man-icmp-srv6-= vpn" data-outlook-id=3D"55a3c979-3d50-466f-a084-3fc49c66da65"> = https://datatracker.ietf.org/doc/html/draft-varhal-6man-icmp-srv6-vpn</a><= br> Diff: <a = href=3D"https://author-tools.ietf.org/iddiff?url2=3Ddraft-varhal-6man-icmp= -srv6-vpn-01" data-outlook-id=3D"8b60d33e-3aac-48af-a0e9-1d33a3ffaf76"> = https://author-tools.ietf.org/iddiff?url2=3Ddraft-varhal-6man-icmp-srv6-vp= n-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 -- [email protected]<br> To unsubscribe send an email to [email protected]<br> </div> </div> </div> _______________________________________________<br>spring mailing list = -- [email protected]<br>To unsubscribe send an email to = [email protected]<br></div></blockquote></div><br></body></html>= --Apple-Mail=_ED115FBA-F6FA-4912-8E08-D80369723106-- --===============4696857408310237559== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5nIG1h aWxpbmcgbGlzdCAtLSBzcHJpbmdAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp bCB0byBzcHJpbmctbGVhdmVAaWV0Zi5vcmcK --===============4696857408310237559==--