Krzysztof, You are correct. When the ping/traceroute probe originates outside of the SRv6 network, example on a CE device, then the relay function as described in RFC 2473 will only work for prefixes in the global routing table and which are resolved to an SRv6 tunnel. The ingress PE cannot perform a relay function for prefixes resolved in a VRF.
If the probe originates at the SRv6 PE router, then the relay function can translate the ICMP error received from the SRv6 transit router into the correct routing context in both a VRF and the global routing table. The other point related to RFC 2473 is that the transit SRv6 router must always originate the ICMP reply back to the ingress SRv6 PE. So, the ICMP tunneling feature is not an alternative to it as stated in your draft, it is an alternative to the ICMP relay function. Regards, Mustapha. From: Krzysztof Szarkowicz <kszarkow...@juniper.net> Date: Friday, July 25, 2025 at 10:10 AM To: Mustapha Aissaoui (Nokia) <mustapha.aissa...@nokia.com> Cc: Zafar Ali (zali) <zali=40cisco....@dmarc.ietf.org>, Alexander Vainshtein <alexander.vainsht...@rbbn.com>, draft-ali-6man-srv6-vpn-icmp-error-handl...@ietf.org <draft-ali-6man-srv6-vpn-icmp-error-handl...@ietf.org>, 6...@ietf.org <6...@ietf.org>, Mr. Zafar Ali <z...@cisco.com>, SPRING WG List <spring@ietf.org> Subject: Re: draft-ali-6man-srv6-vpn-icmp-error-handling CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Mustapha, Behavior described in RFC 2473, Section 8 cannot be really used for SRv6 networks. In SRv6, typically ingress PE, when doing IPv6 encap, uses local IPv6 loopback address as the source IPv6 address in the outer header. For all services (i.e., say for all 100 locally configured VRFs). Based on RFC 2473, Section 8, If some transit router would send ICMP error message to the tunnel ingress, how the ingress PE could determine, in which VRF context (out of 100 locally configured VRFs) the to handle it? This problem is highlighted in Section 2 of draft-ali-6man-srv6-vpn-icmp-error-handling, as Zafar already quoted: When the packet comes to P1, the hop limit expires at P1. Without ICMP tunneling enabled on P1, P1 implements the standard procedure from RFC9259<https://datatracker.ietf.org/doc/html/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))]) the Processing the message at PE1 requires context that the packet was not sourced at PE1. Rules described in RFC 2473, Section 8 do not provide such context. Regards, -- 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 24, at 23:01, Mustapha Aissaoui (Nokia) <mustapha.aissa...@nokia.com> wrote: [External Email. Be cautious of content] Hi Zafar, As far as I know, RFC 9259 did not cover reporting by SRv6 transit routers of ICMP errors when the original probe was for an address of a IPv4/IPv6 prefix which is in the SRv6 service overlay (ICMP message has its own IPv4/IPv6 header which is then encapsulated into SRv6). It only covered ping/traceroute for an IPv6 address of a prefix in the SRv6 underlay (ICMP message encapsulated directedly into SRv6). So, it is a good thing to lay out the procedures of the former case. I would however point that some of the elements of the procedures have been defined in https://datatracker.ietf.org/doc/html/rfc2473#section-8<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc2473*section-8__;Iw!!NEt6yMaO-gk!CQq_FdKjC1gmIXsGJG4jQ7N1Vqiian8wAqFRv79hihx0kcrkd9DMQMiDKTMEWmjTVjCAp5ToOHpDhefmyEnrsOAOGLTzd08$>. This RFC, which builds on a few earlier RFCs, specifies that an ICMP reply must always be sent to the ingress of the outer IP tunnel. In addition, the ingress of the outer IP tunnel will in some cases “relay” the received ICMP error message to the source address of the original payload packet by translating it into the proper error code (it is not an exact 1-to-1 replication of the error code). So, we are dealing with a couple of ICMP error reply messages and not one. The way I interpret this is in the context of SRv6 is as follows: 1. A transit SRv6 router must always send an ICMP error message to the ingress of the SRv6 tunnel and include the IP header and leading payload octets of the original datagram. This is always required. 2. The translation and relaying of the ICMP error message could be done in a few ways. The ingress of the SRv6 tunnel can perform the relay function as described in RFC 2473 or an ICMP tunneling function can perform it at the transit SRv6 router along the lines of what you are proposing in your draft. Regards, Mustapha. From: Zafar Ali (zali) <zali=40cisco....@dmarc.ietf.org<mailto:zali=40cisco....@dmarc.ietf.org>> Date: Thursday, July 24, 2025 at 6:45 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>, Krzysztof Szarkowicz <kszarkow...@juniper.net<mailto:kszarkow...@juniper.net>> Cc: draft-ali-6man-srv6-vpn-icmp-error-handl...@ietf.org<mailto:draft-ali-6man-srv6-vpn-icmp-error-handl...@ietf.org> <draft-ali-6man-srv6-vpn-icmp-error-handl...@ietf.org<mailto:draft-ali-6man-srv6-vpn-icmp-error-handl...@ietf.org>>, 6...@ietf.org<mailto:6...@ietf.org> <6...@ietf.org<mailto:6...@ietf.org>>, Zafar Ali (zali) <z...@cisco.com<mailto:z...@cisco.com>>, SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>> Subject: [spring] Re: draft-ali-6man-srv6-vpn-icmp-error-handling CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for additional information. 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 <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Date: Thursday, July 24, 2025 at 4:37 AM To: Krzysztof Szarkowicz <kszarkow...@juniper.net<mailto:kszarkow...@juniper.net>> Cc: draft-ali-6man-srv6-vpn-icmp-error-handl...@ietf.org<mailto:draft-ali-6man-srv6-vpn-icmp-error-handl...@ietf.org> <draft-ali-6man-srv6-vpn-icmp-error-handl...@ietf.org<mailto:draft-ali-6man-srv6-vpn-icmp-error-handl...@ietf.org>>, 6...@ietf.org<mailto:6...@ietf.org> <6...@ietf.org<mailto:6...@ietf.org>> 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 <kszarkow...@juniper.net<mailto:kszarkow...@juniper.net>> Sent: Wednesday, July 23, 2025 10:14 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Cc: draft-ali-6man-srv6-vpn-icmp-error-handl...@ietf.org<mailto:draft-ali-6man-srv6-vpn-icmp-error-handl...@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org> 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 <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> 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 -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
