[spring] Requirements on SRv6+VPN+ICMP (was New draft: dra ft-varhal-6man-icmp-srv6-vpn-00.txt)
Balázs Varga A <[email protected]> Wed, 4 Mar 2026 14:42:12 +0000
| Newsgroups | gmane.ietf.spring,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <AM0PR07MB5938B122DDBEA97A43E9F07EAC7CA@AM0PR07MB5938.eurprd07.prod.outlook.com> |
--===============0444908168907961083==
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_AM0PR07MB5938B122DDBEA97A43E9F07EAC7CAAM0PR07MB5938eurp_"
--_000_AM0PR07MB5938B122DDBEA97A43E9F07EAC7CAAM0PR07MB5938eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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
--_000_AM0PR07MB5938B122DDBEA97A43E9F07EAC7CAAM0PR07MB5938eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of=
fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang=3D"EN-US" link=3D"#467886" vlink=3D"#96607D" style=3D"word-wrap:=
break-word">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">this is a mail thread to sort out the expectations o=
n <o:p></o:p></p>
<p class=3D"MsoNormal">a VPN ping/trace solution in SRv6 networks. It was <=
o:p></o:p></p>
<p class=3D"MsoNormal">triggered by discussions on the mailing list, after<=
o:p></o:p></p>
<p class=3D"MsoNormal">two solutions were drafted (so far).<o:p></o:p></p>
<p class=3D"MsoNormal">The two drafts are:<o:p></o:p></p>
<p class=3D"MsoNormal">- draft-ali-6man-srv6-vpn-icmp-error-handling<o:p></=
o:p></p>
<p class=3D"MsoNormal"><span lang=3D"DE">- draft-varhal-6man-icmp-srv6-vpn<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"DE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal">Background:<o:p></o:p></p>
<p class=3D"MsoNormal">Diagnostics in VPNs has its own challenges. It was <=
o:p></o:p></p>
<p class=3D"MsoNormal">identified and solved for MPLS based VPNs in the pas=
t. <o:p>
</o:p></p>
<p class=3D"MsoNormal">MPLS technology has its special encapsulation, i.e.,=
<o:p></o:p></p>
<p class=3D"MsoNormal">the MPLS header is a label stack. In case of MPLS, P=
<o:p></o:p></p>
<p class=3D"MsoNormal">routers have no options to identify the ingress of <=
o:p></o:p></p>
<p class=3D"MsoNormal">the MPLS tunnel, as labels in the header point <o:p>=
</o:p></p>
<p class=3D"MsoNormal">towards the network egress point. This characteristi=
c <o:p></o:p></p>
<p class=3D"MsoNormal">restricted the possible solutions to provide VPN <o:=
p></o:p></p>
<p class=3D"MsoNormal">specific ICMP handling in MPLS networks.<o:p></o:p><=
/p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">SRv6 has a different encapsulation, that could make =
<o:p></o:p></p>
<p class=3D"MsoNormal">it possible to remove some of the restrictions of<o:=
p></o:p></p>
<p class=3D"MsoNormal">the MPLS based approach. Maybe one the most painful =
<o:p></o:p></p>
<p class=3D"MsoNormal">limitation of MPLS VPN trace is that it requires<o:p=
></o:p></p>
<p class=3D"MsoNormal">failure-free path between the ingress PE and the <o:=
p></o:p></p>
<p class=3D"MsoNormal">egress PE, what limits its usability during <o:p></o=
:p></p>
<p class=3D"MsoNormal">troubleshooting. <o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">So, now we have the opportunity to make VPN trace<o:=
p></o:p></p>
<p class=3D"MsoNormal">differently in SRv6 networks, IF it is worth to do<o=
:p></o:p></p>
<p class=3D"MsoNormal">so. Please, share your view and help to extend or<o:=
p></o:p></p>
<p class=3D"MsoNormal">simplify the requirement list below.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">List of minimum expectations identified so far:<o:p>=
</o:p></p>
<p class=3D"MsoNormal">R1) able to identify the location of a broken <o:p><=
/o:p></p>
<p class=3D"MsoNormal">connectivity between ingress-PE and egress-PE<o:p></=
o:p></p>
<p class=3D"MsoNormal">R2) keep P nodes service agnostic<o:p></o:p></p>
<p class=3D"MsoNormal">R3) support IPv6-only P nodes <o:p></o:p></p>
<p class=3D"MsoNormal">R4) support any VPN topology<o:p></o:p></p>
<p class=3D"MsoNormal">R5) compliant to existing standards, like [RFC4443]<=
o:p></o:p></p>
<p class=3D"MsoNormal">R6) ... other ???<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">It is always good to agree on WHAT we intend to solv=
e. <o:p>
</o:p></p>
<p class=3D"MsoNormal">Please, chime in and share your view.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Thanks & Cheers<o:p></o:p></p>
<p class=3D"MsoNormal">Bala'zs<o:p></o:p></p>
</div>
</body>
</html>
--_000_AM0PR07MB5938B122DDBEA97A43E9F07EAC7CAAM0PR07MB5938eurp_--
--===============0444908168907961083==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5nIG1h
aWxpbmcgbGlzdCAtLSBzcHJpbmdAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp
bCB0byBzcHJpbmctbGVhdmVAaWV0Zi5vcmcK
--===============0444908168907961083==--