Why is it unspecified what the behavior is if the arg bits are
non-zero. Leaving things unspecified (and getting different behaviors
from different implementations) makes things more complex if we need to
build on this behavior.
Yours,
Joel
On 9/7/2023 10:30 AM, Francois Clad wrote:
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
