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 > <[email protected]> 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 -- [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]
