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’t 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’t 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: > > Without getting into the details, let me ask about what I see as one > important difference in the two approaches. > > 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. > > Is there some way that I am missing that draft-ali allows one to determine > where a path failure is occurring? > > Thank you, > > Joel > > On 4/15/2026 7:14 AM, Krzysztof Szarkowicz wrote: >> Hi Balázs, >> >> >> Thank you for your comments. Please see my responses inline. >> >> >> Cheers, >> Krzysztof >> >> >>> On 2026 Apr 2, at 17:06, Balázs Varga A <[email protected]> >>> <mailto:[email protected]> wrote: >>> >>> Hi Krzysztof, >>> >>> many thanks for the review of the updated draft. Reaction as follows: >>> >>> 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): >>> >>> A--PE1--P1--P2==P3==P4--P5--PE2--B >>> >>> 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. >>> >>> 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: “How the PE node is aware of that >> information is out-of-scope in this document.” >> 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-interworking-02#figure-1>: >> Reference multi-domain network topology >> <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-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 ‘4’ >> and node ‘7’. >> >>> 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. >>> >>> Thanks & Cheers >>> Bala'zs >>> >>> >>> >>> From: Krzysztof Szarkowicz <[email protected] >>> <mailto:[email protected]>> >>> Sent: Monday, March 30, 2026 10:01 AM >>> To: Balázs 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 >>> >>> Hi Balázs, >>> >>> >>> 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] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Balazs, >>> I have a couple of comments on this draft. >>> >>> 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_FdKjC1gmIXsGJG4jQ7N1Vqiian8wAqFRv79hihx0kcrkd9DMQMiDKTMEWmjTVjCAp5ToOHpDhefmyEnrsOAOGLTzd08$> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> Regards, >>> Mustapha. >>> >>> From: Balázs Varga A <[email protected] >>> <mailto:[email protected]>> >>> Date: Monday, March 16, 2026 at 9:51 AM >>> 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 >>> >>> >>> 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. >>> >>> >>> >>> Hi, >>> >>> Based on the valuable feedbacks on the lists the draft on >>> "ICMP Error Handling for VPNs in SRv6 Networks" was >>> updated. >>> >>> Thanks & Cheers >>> Bala'zs (and Joel) >>> >>> -----Original Message----- >>> From: [email protected] <mailto:[email protected]> >>> <[email protected] <mailto:[email protected]>> >>> Sent: Monday, March 16, 2026 2:36 PM >>> To: Balázs 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 >>> >>> 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. >>> >>> 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=draft-varhal-6man-icmp-srv6-vpn-01 >>> >>> Abstract: >>> >>> 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. >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> _______________________________________________ >>> 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]> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] <mailto:[email protected]> >> List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/ >> --------------------------------------------------------------------
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
