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]> 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]>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
