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]> 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]> > Date: Monday, March 16, 2026 at 9:51 AM > 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 > > > 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. > > > > 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] <[email protected]> > Sent: Monday, March 16, 2026 2:36 PM > To: Balázs Varga A <[email protected]>; Joel Halpern > <[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] > To unsubscribe send an email to [email protected] > _______________________________________________ > 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]
