[spring] Re: draft-ali-6man-srv6-vpn-icmp-error-handling

["Zafar Ali (zali)" <[e-mail]>]

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 <[e-mail]>
Date: Thursday, July 24, 2025 at 4:37 AM
To: Krzysztof Szarkowicz <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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 <[e-mail]>
Sent: Wednesday, July 23, 2025 10:14 PM
To: Alexander Vainshtein <[e-mail]>
Cc: [e-mail]; [e-mail]
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: [phone]
Please consider my current time zone, when calling: CEST (UTC+02:00)

On 2025 Jul 22, at 17:30, Alexander Vainshtein <[e-mail]<mailto:[e-mail]>> 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.