Hi Joel, Sec. 10.1 specifies how the SR source node should send the ICMP packet so that it is correctly processed by the receiver. I.e., if the source sends an ICMP packet to a SID with a non-zero argument, then they may not get a reply back, as you have observed in your tests.
Thanks, Francois On 7 Sep 2023 at 14:49:20, Joel Halpern <j...@joelhalpern.com> wrote: > Can you explain then what the text is section 10.1 is talking about? It > seems like it is mandating certain bits being 0 for it to be considered a > match? (I will also have to find out more about why the tests showed > certain routers dropping such packets.) > > Yours, > > Joel > On 9/7/2023 4:09 AM, Francois Clad wrote: > > Hi Joel, > > The receiver in this case is an SR segment endpoint node processing an > IPv6 packet that matches a FIB entry locally instantiated as a SID of this > document. Therefore, the expected behavior of the receiver is that > described in Sec. 4. > > Thanks, > Francois > > On 6 Sep 2023 at 16:38:30, Joel Halpern <j...@joelhalpern.com> wrote: > >> Askign as a participant: >> >> In section 10.1 it says: >> >> When the SRv6 SID in the destination address of the ICMPv6 echo request >> is one of the SID flavors defined in this document, the SR source node MUST >> set the arguments of the SID to 0 >> >> What is a receiver required to do if it gets an improper ICMP, e.g. a >> ping to aa compressed SID with non-zero argument? Reports from tests show >> one implementation dropping the ping and another implementation responding >> to it. >> >> Thank you, >> >> Joel >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
