Hi Feng, Many thanks for your review and comment.
Yes, this is an important topic for discussion. The requirement from draft-varhal-6man-icmp-srv6-vpn perspective is: to use a VPN-specific SID (i.e., such a SID refers to the VPN where the source of the inner packet is located). Any SID that fulfills that need can be used, so a more specific SID can be used as well. So, for the ICMP processing in draft-varhal no "flow specific SID" is needed like in your draft (draft-yang-spring-sid-as-source-address), but it is not prohibited to do so. Thanks Bala'zs -----Original Message----- From: [email protected] <[email protected]> Sent: Wednesday, July 15, 2026 5:16 AM To: 'Balázs Varga A' <[email protected]>; 'SPRING WG' <[email protected]> Cc: [email protected] Subject: [spring] 回复: New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt Hi Varga, I have some comments. In section "3.2. Details of ICMP Error Handling for VPNs in SRv6 Networks", the solution requires "The solution uses a per-vrf SID (e.g., End.DT6) in the IP SA of the SRv6 encapsulated packets.". Would it be as good idea to use more specific SID (per-prefix or per-link)? If the user traffic uses SID as source, this will keep the traffic address aligned with the user traffic. See https://datatracker.ietf.org/doc/html/draft-yang-spring-sid-as-source-address-13#name-ip-vpn-over-srv6. BR, Feng -----邮件原件----- 发件人: Balázs Varga A <[email protected]> 发送时间: 2026年2月26日 16:53 收件人: SPRING WG <[email protected]> 抄送: [email protected] 主题: [spring] New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt Hi, As this draft focuses on SRv6, the notification is sent to the spring list as well. Thanks & Cheers Bala'zs -----Original Message----- From: Balázs Varga A Sent: Wednesday, February 25, 2026 9:18 AM To: IPv6 List <[email protected]> Subject: New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt Hi, We have uploaded a new draft on "ICMP Error Handling for VPNs in SRv6 Networks". The draft proposes a solution that provides a native IPv6 method what does NOT have the drawbacks inherited by methods based on the MPLS based VPN ping or traceroute concept. It solves the problem that P nodes are not VPN aware without sending the ICMP error message to the egress PE router for a VPN lookup. It makes P nodes service agnostic and allows building IPv6-only core networks. Comments and suggestions are welcome. Thanks & Cheers Bala'zs -----Original Message----- From: [email protected] <[email protected]> Sent: Wednesday, February 25, 2026 8:07 AM To: Balázs Varga A <[email protected]>; Joel Halpern <[email protected]> Subject: New Version Notification for draft-varhal-6man-icmp-srv6-vpn-00.txt A new version of Internet-Draft draft-varhal-6man-icmp-srv6-vpn-00.txt has been successfully submitted by Balazs Varga and posted to the IETF repository. Name: draft-varhal-6man-icmp-srv6-vpn Revision: 00 Title: ICMP Error Handling for VPNs in SRv6 Networks Date: 2026-02-24 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-varhal-6man-icmp-srv6-vpn-00.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 Abstract: This document specifies ICMP error handling in SRv6-based Virtual Private Networks. 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]
