[spring] Re: Requirements on SRv6+VPN+ICMP (was New draft: draft-varhal-6man-icmp-srv6-vpn-00.txt)

[Krzysztof Szarkowicz <[e-mail]>]

HI Balázs,

I am not sure, what you mean by “compliant to existing standards”. Are you planning for “Informational" (not “Standard Track”) RFC? Please note, that draft-varhal-6man-icmp-srv6-vpn changes (comparing to “existing standards”) the ICMP processing on PE node, while draft-ali-6man-srv6-vpn-icmp-error-handling changes the ICMP processing on P node -> both proposals modify some existing standards.

For the requirements, in addition to listed requirements (except R5, which is not fully clear to me), important is:

1) should work in mixed MPLS/SRv6 environment (migration scenarios): Mo6, 6oM, MPLS<->SRv6 encap conversions
2) invoking node, initiating IPv4 traceroute, should be able to display real IPv4 address of the P node, if P node has IPv4 address, in addition to IPv6 address (again, mixed MPLS/SRv6 environment during migrations)
3) invoking node, initiating IPv4 traceroute, should be able to display real IPv6 address of the P node, if P node has only IPv6 address (pure SRv6 environment)
4) should work in architectures with multi-level IP encapsulations (i.e. at some transit node without service awareness additional IP encapsulation is pushed on the packet -> for example expansion of B-SID with ‘Encaps’ flavor)

Cheers,
Krzysztof


> On 2026 Mar 4, at 15:42, Balázs Varga A <balazs.a.varga=[e-mail]> wrote:
> 
> Hi,
>  
> this is a mail thread to sort out the expectations on 
> a VPN ping/trace solution in SRv6 networks. It was 
> triggered by discussions on the mailing list, after
> two solutions were drafted (so far).
> The two drafts are:
> - draft-ali-6man-srv6-vpn-icmp-error-handling
> - draft-varhal-6man-icmp-srv6-vpn
>  
> Background:
> Diagnostics in VPNs has its own challenges. It was 
> identified and solved for MPLS based VPNs in the past. 
> MPLS technology has its special encapsulation, i.e., 
> the MPLS header is a label stack. In case of MPLS, P 
> routers have no options to identify the ingress of 
> the MPLS tunnel, as labels in the header point 
> towards the network egress point. This characteristic 
> restricted the possible solutions to provide VPN 
> specific ICMP handling in MPLS networks.
>  
> SRv6 has a different encapsulation, that could make 
> it possible to remove some of the restrictions of
> the MPLS based approach. Maybe one the most painful 
> limitation of MPLS VPN trace is that it requires
> failure-free path between the ingress PE and the 
> egress PE, what limits its usability during 
> troubleshooting. 
>  
> So, now we have the opportunity to make VPN trace
> differently in SRv6 networks, IF it is worth to do
> so. Please, share your view and help to extend or
> simplify the requirement list below.
>  
> List of minimum expectations identified so far:
> R1) able to identify the location of a broken 
> connectivity between ingress-PE and egress-PE
> R2) keep P nodes service agnostic
> R3) support IPv6-only P nodes 
> R4) support any VPN topology
> R5) compliant to existing standards, like [RFC4443]
> R6) ... other ???
>  
> It is always good to agree on WHAT we intend to solve. 
> Please, chime in and share your view.
>  
> Thanks & Cheers
> Bala'zs
> _______________________________________________
> spring mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>