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] To unsubscribe send an email to [email protected]
