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 Hal
Hello,
I am interested in doing the review for draft-ietf-spring-srv6-srh-compression
as well, and I qualify according to the criteria you get.
Best regards,
Antoine
-Original Message-
From: spring On Behalf Of Joel Halpern
Sent: mercredi 6 septembre 2023 19:12
To: SPRING WG List
Sub
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, Fr
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
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 Joe
Hi Joel,
This behavior is not unspecified. It is specified in Sec. 4 of the draft
(as mentioned in my first email). Given the same packet and the same router
configuration, the behavior should be the same with all implementations.
Thanks,
Francois
On 7 Sep 2023 at 16:32:06, Joel Halpern wrote:
