Hi Sasha
Many thanks for a fruitful meeting offline.
As per your suggestion, I am adding Spring.
Re: The situation with MPLS-encapsulated IP-VPN packets is different
This is an excellent observation, and you are right.
The draft acknowledges the fact that IPv6 case is different than MPLS.
“Without ICMP tunneling enabled on P1, P1 implements the standard procedure
from RFC9259, and therefore sends an ICMPv6 packet towards PE1 as
follows:
P1_out : (P1::1, PE1::1, HL=64, NH=ICMPv6)
(ICMPv6, Time Exceeded,
[copy of the invoking packet =
(PE1::1, PE2:DT6::, HL=1, NH=IPv6)
((CE1::1, CE2::1, HL=1, NH=UDP)(Traceroute probe))])”
It then lists the motivations for proposing this optional “alternate” procedure
(to tunnel ICMP messages).
Re: the update tag
The scope of processing is an SRv6 capable node with the capability enabled for
it.
The processing at P node is also limited to the packets where destination of
the upper IPv6 header (provide header) is in the SRv6 LOC block, e.g.,
5f00::/16 [rfc9602] (which is known to all SRv6 nodes in any deployment). The
procedure is never applied to ICMP error handing for packets with destination
outside SRv6 LOC block. Therefore, we believe it is backward compatible.
No changes to ICMP error processing are suggested (just adds an optional
alternate way to “transport” ICMP error message.
Thanks
Regards … Zafar
From: Alexander Vainshtein <[email protected]>
Date: Thursday, July 24, 2025 at 4:37 AM
To: Krzysztof Szarkowicz <[email protected]>
Cc: [email protected]
<[email protected]>, [email protected]
<[email protected]>
Subject: RE: draft-ali-6man-srv6-vpn-icmp-error-handling
Krzysztof,
Lots of thanks for your email.
I would like to clarify that I do not have any problems with the solution
proposed in the draft.
I was just trying to say that
* The situation with MPLS-encapsulated IP-VPN packets is different
* The proposal modifies an existing Standards Track RFC - with all the
implications (text, process etc.).
My 2c,
Sasha
From: Krzysztof Szarkowicz <[email protected]>
Sent: Wednesday, July 23, 2025 10:14 PM
To: Alexander Vainshtein <[email protected]>
Cc: [email protected]; [email protected]
Subject: [EXTERNAL] Re: draft-ali-6man-srv6-vpn-icmp-error-handling
Importance: High
Hi Sahsa,
Indeed, that are good comments. Thank you for providing them.
We will be taking these comments in the next version of the draft.
Please see as well my one comment inline.
--
Krzysztof Grzegorz Szarkowicz, HPE Networking PLM, Solutions Architect | Phone:
+49 89 203 012 127
Please consider my current time zone, when calling: CEST (UTC+02:00)
On 2025 Jul 22, at 17:30, Alexander Vainshtein
<[email protected]<mailto:[email protected]>> wrote:
[External Email. Be cautious of content]
Hi,
I have watched the presentation of the
draft<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ali-6man-srv6-vpn-icmp-error-handling-00__;!!NEt6yMaO-gk!AGUwJRsj-OEw3JuEo5_a5D_zet7e9jK64lzPkSjSJeO2kUwWMXdrxPamVAcN1_roA4oDKbLt0v6-hHLRNepvkvyT5uN7QZc$>
at the 6MAN WG session in Madrid today, and I have also looked up the draft
after the session was over.
I think that the analogy with using the uniform model for TTL handling in MPLS
that the draft acknowledges is problematic:
When the TTL in the top label in the label stack of an MPLS-encapsulated
customer IP packet used for traceroute and this packet is trapped to the CP,
the CP knows that this is a labeled packet. It can then look up at the first
nibble of the payload (immediately following the BOS), recognize the packet as
IPv4 or IPv6, generate a suitable ICMP error message with the destination IPv4
or IPv6 address taken from the MPLS-encapsulated IP header and tunnel it to the
remote PE by pushing the label stack of the trapped labeled packet and using
the top label to identify the egress interface and the next hop. (The CP does
not have any alternatives because MPLS LSPs are unidirectional and does not use
any kind of ICMP)
[Krzysztof] Not sure, what exactly problem you see. In the draft, the text
says, that destination destination IPv4 or IPv6 address from the most inner
header is taken (in case, there are more headers), and the packet is tunneled
to the remote PE by pushing the original stack of IPv6 headers (just modifying
the top header: changing the source address to local address, and initializing
HL). Destination IPv6 address of top header is used to identify the egress
interface and the next hop. Not sure, what problems you see here.
When the HL in the IPv6 header pushed by the ingress PE on the customer IP
packet used for traceroute expires and this packet is trapped to the CP, the CP
sees just an IPv6 packet with HL expired. There is source IPv6 address in the
IPv6 header, so that the normal reaction of the CP would be to create an ICMPv6
error message with the destination address taken from the source IP address in
this header, i.e., IP address of the ingress PE. This is standardized in
Section 3.3 of RFC
4443<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4443*section-3.3__;Iw!!NEt6yMaO-gk!AGUwJRsj-OEw3JuEo5_a5D_zet7e9jK64lzPkSjSJeO2kUwWMXdrxPamVAcN1_roA4oDKbLt0v6-hHLRNepvkvyTkyjjX4k$>
– but this is not what you would like to see.
From my POV the draft proposes (without explicitly stating that) to change the
standard processing of the HL Expired events in IPv6 along the following lines:
If the Next Header value in the IPv6 header of an IPv6 packet trapped due to HL
expiration is IPv6 or IPv4, consider this packet as an received a
SRV6-encapsulated packet used for CE-to-CE traceroute, generate a suitable
ICMPv6/ICMP error message, push the IPv6 header with high enough HL value and
the rest of the fields copied from the UIPv6 header of the trapped packet and
subject it to IPv6 forwarding.
If f the above understanding is correct, then:
The draft:
Indeed should be handled by the 6MAN WG
The intended status should remain Standards Track
The metadata should say that the draft updates RFC 443 (if approved)
The text should be augmented with appropriate IETF terms expressing requirement
levels and explicitly define the desired behavior using these terms (instead of
or in addition to) illustrations. It should also address the situations in
which the IPv6 header is following by the SRH header etc.
Hopefully, these notes will be useful.
Regards,
Sasha
Disclaimer
This e-mail together with any attachments may contain information of Ribbon
Communications Inc. and its Affiliates that is confidential and/or proprietary
for the sole use of the intended recipient. Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly
prohibited. If you are not the intended recipient, please notify the sender
immediately and then delete all copies, including any attachments.
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
