[the chair hat's on] Hello,
A friendly reminder to ensure our technical discussions remain constructive and valuable for everyone: Be respectful and polite: Please maintain a respectful tone in all communications. We are a community working toward shared goals. Critique the solution, not the person: When providing feedback, ensure your comments are focused solely on the technical content of the proposal. Please refrain from making remarks about the individual who submitted the work. Thank you for helping us maintain a productive environment! On Mon, Oct 20, 2025 at 11:49 PM Mike Simpson <[email protected]> wrote: > Are you using HL counting out as a means to do something? > It looks like what you are wanting is that HL will count down but at the > point at which the packet is discarded you want it to “de-encapsulate” the > SRV6 address, give it another non-zero HL, then send it on its way. > > What’s the point of HL in your scenario? Why can you resurrect a packet > that has exceeded its hop limit. How are you able to demonstrate that this > will never lead to rogue behaviour and if your answer to that is “limited > domain” then this is just self-interest motivated shenanigans and is > exactly the sort of BS that the IETF should have been able to resist if it > wasn’t for malignant behaviour by vendors who only care about their > quarterly earnings report. > > It’s like a bad joke. “When is a hop limit not a hop limit” > > These changes are going to go down in our short history as the worst > changes to be inflicted on the internetworks ever and will be as a direct > result of sociopathic behaviour. > -please remember that the people shoving this through don’t care about the > damage they will do. > They and the vendors that are behind them driving this aren’t working for > the common good. > > All of this needs to have its own special corner where its vendors can > deploy it. An actual walled garden, as it is allowing this crap to claim > that it’s IPv6 in its header means that it is going to be appearing > everywhere and causing all sorts of trouble to a huge proportion of the > *gigantic amounts of deployed running code*. > -we surely realise by now that “limited domain” is code for at best > “someone else’s problem” > > Forcing them to have a new protocol version means that all the current > install base will have a chance at handling it gracefully and anyone that > has to use the new features can be the ones to deploy it and the rest of us > get the choice rather than having it forced down our pipes. > > We used to prioritise deployed code. How did the culture change to the > point where we are thinking of doing this? > > > > LOn 17 Oct 2025, at 15:15, Zafar Ali (zali) <zali= > [email protected]> wrote: > > > > Hello Mustapha, > > > > Many thanks for your comments – much appreciated! > > Based on your feedback, we have added further clarification w.r.t. to the > procedure in [RFC2473], Section 8. > > Please see updates in > https://www.ietf.org/archive/id/draft-ali-6man-srv6-vpn-icmp-error-handling-01.txt > > We will be happy to provide any additional clarification in the draft. > > > > Please advise if you have any further comments. > > > > Thanks > > > > Regards … Zafar > > > > *From: *Mustapha Aissaoui (Nokia) <[email protected]> > *Date: *Friday, July 25, 2025 at 2:30 PM > *To: *Krzysztof Szarkowicz <[email protected]> > *Cc: *Zafar Ali (zali) <[email protected]>, Alexander > Vainshtein <[email protected]>, > [email protected] < > [email protected]>, [email protected] < > [email protected]>, Zafar Ali (zali) <[email protected]>, SPRING WG List < > [email protected]> > *Subject: *Re: draft-ali-6man-srv6-vpn-icmp-error-handling > > 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 <[email protected]> > *Date: *Friday, July 25, 2025 at 10:10 AM > *To: *Mustapha Aissaoui (Nokia) <[email protected]> > *Cc: *Zafar Ali (zali) <[email protected]>, Alexander > Vainshtein <[email protected]>, > [email protected] < > [email protected]>, [email protected] < > [email protected]>, Mr. Zafar Ali <[email protected]>, SPRING WG List < > [email protected]> > *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) < > [email protected]> 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) <[email protected]> > *Date: *Thursday, July 24, 2025 at 6:45 AM > *To: *Alexander Vainshtein <[email protected]>, Krzysztof > Szarkowicz <[email protected]> > *Cc: *[email protected] < > [email protected]>, [email protected] < > [email protected]>, Zafar Ali (zali) <[email protected]>, SPRING WG List < > [email protected]> > *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 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 <[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]> 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. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/ > -------------------------------------------------------------------- > > _______________________________________________ > spring mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Cheers, Jen Linkova
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
