Hi Balázs,
Thank you for your comments. Please see my responses inline.
Cheers,
Krzysztof
On 2026 Apr 2, at 17:06, Balázs Varga A
<[email protected]> wrote:
Hi Krzysztof,
many thanks for the review of the updated draft. Reaction as follows:
1, Multiple IP encapsulation (e.g., B-SID):
I do not think this is an VPN-specific issue. It is a more general one.
Let's assume such a network (B-SID used between P2/P3/P4):
A--PE1--P1--P2==P3==P4--P5--PE2--B
If You are tracerouting PE2 from PE1 and Your HL expire at P3, as
per current
RFCs, the ICMP error is sent to P2 and PE1 will not receive the
ICMP error
message. The multiple encapsulation part of the path is not visible
for the
traceroute.
Note, that there are no VPNs in the above example. The issue is not
VPN specific,
but VPN traceroute also suffers from this unwanted characteristics.
I think we agree that here we need a solution, but I would not
expect from a
VPN specific solution to solve it. We need a more general one.
[Krzysztof] Indeed. Hence, authors of
draft-ali-6man-srv6-vpn-icmp-error-handling proposed a solution to
solve this (among many others) use case.
2, Real IPv4 address of 'P' node:
This is covered in the draft. Please, double check the last
paragraph in
section 3.4. It is also part of the illustration in Section 3.5
(see the last
PE1_out packet at the end of the section).
[Krzysztof] I see in the draft: “How the PE node is aware of that
information is out-of-scope in this document.”
draft-ali-6man-srv6-vpn-icmp-error-handling, on the other hand,
covers that use case as well.
3. Handling migration/interop (MPLS <-> SRv6) scenarios:
Please clarify by describing the scenario details You are referring
to. Many thanks.
[Krzysztof] For example, Mo6
(draft-ietf-spring-srv6-mpls-interworking-02, Section 7.1.1.2).
Topology diagram from the draft:
+-----+ +-----+ RD:V/v via 10 +-----+
.......|S-RR1|<...............|S-RR2|<.................|S-RR3| <..
: +-----+ +-----+ +-----+ :
: :
: :
+--:-------------------+----------------------+---------------------:-+
| : | 2 | | | 5 | | | 8 | : |
| : +---+ | +---+ | +---+ : |
| : | | : |
| : | | : |
| : | | : |
|----+ IGP1 +---+ IGP2 +---+ IGP3 +----|
| 1 | | 4 | | 7 | | 10 |
|----+ +---+ +---+ +----|
| | | |
| | | |
| | | |
| +---+ | +---+ | +---+ |
| | 3 | | | 6 | | | 9 | |
+----------------------+----------------------+-----------------------+
iPE iBR eBR ePE
<----------LI---------><----------C----------><-----------LE---------->
Figure 1
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-02#figure-1>:
Reference multi-domain network topology
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-02#name-reference-multi-domain-netw>
In Mo6, IGP1 and IGP3 are MPLS domains, whereas IGP2 is SRv6 domain.
Assume, TTL/HC expires in IGP2 (SRv6 domain) at some transit node
between node ‘4’ and node ‘7’.
4. Handling VPNs with DX4/DX6 SIDs:
This is covered in the draft. Please, double check Section 3.2. The
paragraph after
the "Packet processing" steps clarifies it in detail.
[Krzysztof] I see following in the draft:
More specifically for a VPN service the PE node can allocate SID(s)
per-prefix (e.g., End.DX6) or per-vrf (e.g., End.DT6). The solution
uses a per-vrf SID (e.g., End.DT6) in the IP SA of the SRv6
encapsulated packets.
So, no description about deployments using DX4/DX6. Draft addresses
only deployments using DT4/DT6/DT46.
5. Handling of Hub-and-Spoke VRFs:
This is covered in the draft. Please, double check Section 3.2. The
second paragraph
after the "Packet processing" steps clarifies it in detail.
[Krzysztof] in the draft I see:
For more sophisticated VPN configurations (e.g., Hub-and-Spoke VPN)
where multiple VRFs (and SIDs) are configured for a given VPN, the
VPN specific SID of PE1 always refers to the VRF instance (and its
per-vrf SID) where the prefixes of the connected customer site(s)
can be looked up.
Draft assumes per-VRF SID, while many hub-and-spoke deployments use
per-CE SID, to prevent IP lookup inside spoke VRF and thus to
prevent unintentional direct CE-to-CE communication inside spoke VRF.
6. Routable VPN-specific SID + multi-domain scenario:
Multi-domain has its side-effects. See reply regarding item 1).
[Krzysztof] Indeed. The authors of
draft-ali-6man-srv6-vpn-icmp-error-handling realized that, and
proposed solution in the draft-ali-6man-srv6-vpn-icmp-error-handling
to address this.
7. Different visibility for served VPNs
Yes, this section needs some further clarification. It is an
additional (optional)
capability of the VPN-associated-ICMP-process-function. We will
update for the
next version.
Thanks & Cheers
Bala'zs
*From:*Krzysztof Szarkowicz <[email protected]>
*Sent:*Monday, March 30, 2026 10:01 AM
*To:*Balázs Varga A <[email protected]>
*Cc:*SPRING WG List <[email protected]>; IPv6 List <[email protected]>;
Mustapha Aissaoui (Nokia) <[email protected]>
*Subject:*Re: [spring] New Version Notification for
draft-varhal-6man-icmp-srv6-vpn-01.txt
Hi Balázs,
I have checked the updated version of the draft. It addresses some
shortcomings of this solution raised for initial version of the
draft, but is still doesn't address many other shortcomings:
1. Handling of multiple IP encapsulations (e.g. expanding of B-SID
with encap mode) on the node that is not service aware - i.e.,
B-SID is expanded on a node without VRF, and with no service prefix
visibility)
2. Providing real IPv4 address of 'P' node (when such address
exists - for example during migration scenarios, when dual
IPv4/IPv6 stack is used) to the node invoking IPv4 traceroute
3. Handling migration/interop (MPLS <-> SRv6) scenarios
4. Handling VPNs with DX4/DX6 SIDs, where DT4/DT6/DT46 SIDs are not
deployed
5. Handling of Hub-and-Spoke VRFs, where on PE traffic incoming on
PE-CE interfaces in multiple local VRFs, is forced (vendor
terminology: filter based forwarding, policy based routing, etc.)
via single outgoing VRF (VRF-out)
6. "As the locator part of the VPN-specific SID is routable within
the SRv6 domain other PE and P nodes of the SRv6 domain can
send/route packets to it." -> this is not necessarily true in
multi-domain designs, with B-SID expansion at domain boundaries.
7. "It can hide the SIDs used inside the SRv6 domain and can
provide different visibility for served VPNs if needed." -> Not
sure, if I understand this statement
Cheers,
Krzysztof
On 2026 Mar 18, at 22:30, Mustapha Aissaoui (Nokia)
<[email protected]> wrote:
Hi Balazs,
I have a couple of comments on this draft.
The first one is to referenceRFC 2473
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc2473*section-8__;Iw!!NEt6yMaO-gk!CQq_FdKjC1gmIXsGJG4jQ7N1Vqiian8wAqFRv79hihx0kcrkd9DMQMiDKTMEWmjTVjCAp5ToOHpDhefmyEnrsOAOGLTzd08$>
as
it is well described that an ICMP reply must be sent on the
outer IPv6 header in the case of an IP-in-IP tunnel. For me
this is the closest prior art we can refer to when discussing
potential new solutions, other than ICMP tunneling.
This RFC also describes a general ICMP relay function covering
various ICMP error messages. In the specific context of a
TCP/UDP traceroute probe, this relay function will only work
for traceroute packets of routes in the global routing table as
discussed in an earlier thread on
draft-ali-6man-srv6-vpn-icmp-error-handling. It does however
not address probes sent in VRF context.
The second is regarding the use of a SRv6 service SID as the
source address on the outer IPv6 header. The source address in
the outer IPv6 header is used by downstream routers to report
various ICMP error messages on the SRv6 tunnel, some of which
are ad-hoc and triggered by malformed outer headers in user
packets. Hence it cannot be sent to a specific VRF context of
the ingress SRv6 PE.
I can see a service SID being used as the source address of the
traceroute for probes originating at the ingress SRv6 PE since
the user can configure this specifically for these probes. But
not for probes generated by the CE since they are treated as
user packets at the ingress SRv6 PE and they would inherit the
source address of the SRv6 tunnel. For probes originating at
the ingress SRv6 PE, one can correlate the error message with a
specific VPN or global routing table traceroute probe based on
TCP or UDP port number. So there are alternatives too.
Regards,
Mustapha.
*From:*Balázs Varga A
<[email protected]>
*Date:*Monday, March 16, 2026 at 9:51 AM
*To:*SPRING WG List <[email protected]>, IPv6 List <[email protected]>
*Subject:*[spring] FW: New Version Notification for
draft-varhal-6man-icmp-srv6-vpn-01.txt
CAUTION: This is an external email. Please be very careful when
clicking links or opening attachments. See the URLnok.it/ext
<http://nok.it/ext>for additional information.
Hi,
Based on the valuable feedbacks on the lists the draft on
"ICMP Error Handling for VPNs in SRv6 Networks" was
updated.
Thanks & Cheers
Bala'zs (and Joel)
-----Original Message-----
From:[email protected]<[email protected]>
Sent: Monday, March 16, 2026 2:36 PM
To: Balázs Varga A <[email protected]>; Joel Halpern
<[email protected]>
Subject: New Version Notification for
draft-varhal-6man-icmp-srv6-vpn-01.txt
A new version of Internet-Draft
draft-varhal-6man-icmp-srv6-vpn-01.txt has been successfully
submitted by Balazs Varga and posted to the IETF repository.
Name: draft-varhal-6man-icmp-srv6-vpn
Revision: 01
Title: ICMP Error Handling for VPNs in SRv6 Networks
Date: 2026-03-16
Group: Individual Submission
Pages: 12
URL:
https://www.ietf.org/archive/id/draft-varhal-6man-icmp-srv6-vpn-01.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
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-varhal-6man-icmp-srv6-vpn-01
Abstract:
This document specifies ICMP error handling in SRv6-based
Virtual
Private Networks, that support direct localization of
failures. It
provides a solution for connectivity check and fault
localization
without adding complexity to P nodes and keeps P nodes service
agnostic. ICMP processing is changed only on ingress PE
nodes and
gains from adding VPN-specific information to the SRv6
encapsulated
packet. Egress PE nodes are not involved in the forwarding
of the
ICMP error messages. Therefore, the solution provides visibility
upto the failure even if ingress PE to egress PE connectivity is
broken within the SR domain.
The IETF Secretariat
_______________________________________________
spring mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
spring mailing list [email protected]
To unsubscribe send an email [email protected]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
List Info:https://mailman3.ietf.org/mailman3/lists/[email protected]/
--------------------------------------------------------------------
