[IPv6]Re: New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt

[[e-mail]]

Hi Bala'zs,

Thank you for the productive discussion and considering my comments.
On the "VPN SID flooding", you're correct. There is no need to flood the whole VPN SID, and only the locator part of VPN SID needs to be flooded, if that's already there, adding a reference to this draft would help.
Cheers,
Xiao Min


Original



From: BalázsVargaA <[e-mail]>
  
To: 肖敏10093570;
  
Cc: [e-mail] <[e-mail]>;
Date: 2026年02月27日 18:14
  
Subject: RE: [IPv6]New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt
  




Hi Xiao Min,
 
Ok, note taken regarding item 2. That part will be described with more 
detail in the next version. Thanks for pointing it out.
 
Just a clarification on the “VPN SID flooding” in the underlay network:
The underlay network must be aware only the locator part of the VPN SID.
E.g., B:N::/64 (like the example in RFC8986 Section 3.2) 
 
Thanks & cheers
Bala’zs
 

From: [e-mail] <[e-mail]> Sent: Friday, February 27, 2026 4:10 AM To: Balázs Varga A <[e-mail]> Cc: [e-mail] Subject: Re: [IPv6]New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt


 


Hi Bala'zs,



Thank you for the prompt responses.



Please see inline.



Original




From: BalázsVargaA <[e-mail]>   



To: 肖敏10093570;   



Cc: [e-mail] <[e-mail]>;



Date: 2026年02月26日  18:57  



Subject: RE: [IPv6]New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt  




Hi Xiao Min,
 
Many thanks for your comments. My answers below regarding your good and
essential questions:
 
1, The VPN-associated-SID is locally allocated by the PE. Its processing already
defines the upper-layer header steps (see rfc8986, section 4.1.1). In our case the
upper-layer = ICMPv6, therefore no need for extra parsing rules.  
Anyway, You are right, PE could parse the payload of ICMP Error Message and find
the VPN ID, however it is somewhat more complicated as the VPN specific SID in
the dstIP was allocated by the (remote) egress PE. So, following the already existing
upper-layer processing steps for a locally allocated SID is more simple.

[XM]>>> Make sense to me.



 


2, Yes, this is also a relevant part of the solution. There is no need for extra node SID
per VPN. You can use the same SID per VPN, what was allocated for the VPN service.
Being more specific: for a VPN service one can allocate SID(s) per-prefix (e.g., End.DX6)
or per-vrf (e.g., End.DT6). In the draft we propose to use a per-vrf SID (e.g., End.DT6) in
the srcIP on the PE. SID selection by the remote PE is not affected by the solution.

[XM]>>> I think this part is not clear in the current draft, so you may consider to elaborate it. As far as I know, the VPN SIDs won't be flooded within the SRv6 underlay networks,  however your solution requires the transit nodes between the ICMP Error Message sending node (P node) and the receiving node (ingress PE node) to forward the ICMP Error Message based on VPN SID (as the dstIP), so the VPN SIDs need to be flooded. IMHO that's  a big change and must be documented clearly.



 



Cheers,



Xiao Min



 


Thanks & Cheers
Bala’zs
 

From: [e-mail] <[e-mail]> Sent: Thursday, February 26, 2026 8:49 AM To: Balázs Varga A <[e-mail]> Cc: [e-mail] Subject: Re: [IPv6]New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt


 


Hi Bala'zs,



 



I like to see an alternative proposal for resolving the SRv6 VPN traceroute problem.



Actually I've also noticed the shortcomings of the MPLS based solution stated in section 3.3 of your draft.



After a quick reading I believe your proposed solution works, while I still have two questions as below.



1, Now that some complexity on PE is required by this solution, what's the advantage by using a VPN-associated-SID as the srcIP over applying a local policy to PE? Applying a local policy to PE, I mean mandating PE to parse the payload   of ICMP Error Message and find the VPN ID.



2, If I understand it correctly, this solution requires the PE to advertise multiple node SIDs (one node SID per VPN), then which one SID will be used as the dstIP by the remote PE while doing SRv6 encapsulation? 



 



Cheers,



Xiao Min



Original




From: BalázsVargaA <balazs.a.varga=[e-mail]>    



To: IPv6 List <[e-mail]>;   



Date: 2026年02月25日   16:18  



Subject: [IPv6]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: [e-mail] <[e-mail]> Sent: Wednesday, February 25, 2026 8:07 AM To: Balázs Varga A <[e-mail]>; Joel Halpern <[e-mail]> 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [e-mail] List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/ --------------------------------------------------------------------