FWIW, I agree with most of what Joel wrote. ;-) I see another path forward: Given that the issue is constrained to an SR domain, the draft could also point out the issues as operational/deployment considerations. Operators can then make an informed decision on whether they want to/can use C-SIDs without an SRH in their network. This path forward (or leaving it out of scope, as Joel suggests below) is something the spring WG can reach consensus on by itself (i.e., without needing to consult or agree with other WGs).
Other solutions that may require updates to rfc8200 or, at least, consultation with 6man may also be possible. Those solutions should be discussed with both WGs. While this topic has been discussed before, I suggest at least using a different thread (with a better subject line). Thanks! Alvaro. On March 25, 2024 at 1:25:57 PM, Joel Halpern (j...@joelhalpern.com) wrote: (Speaking technically as an individual, but noting that Alvaro and I are the responsible chairrs who will have to resolve any technical standards incompatibility. And I have not talked with Alvaro. So I may be putting my foot in my mouth.) As I understand it, the current view is that the compressed SID draft permists the case where a single container represents the SR policy. If that contianer is using uSID, and if the packet is going between two hosts in the SRv6 domain, then the SRH may be omitted and no encapsulation is needed. In that case, the sending host needs to compute the checksum based on what the receiver will see. It can do that, and there is text in the draft to do so. There are however two related issues. First, that direction for computing the upper layer checksum does not match what RFC 8200 says. If indeed that is a change to 8200, then that needs to be indicated somehow, and presumably approved by 6man. related to that, any intermediate node looking at the packet will see an apparently ordinary IPv6 packet whose upper layer checksum is incorrect. Tom Herbert, if I am understanding him correctly, is arguing that since the shifting of the uSID container is essentially a DA rewrite, the operation is sufficiently similar to NAT that one should expect the NAT device to correct the checksum (which is a different repair than the current compression draft calls for.) As far as I can tell, this intradomain, non-SRH, uSID case is intendedd to be supported by the compression solution. (Another option for the WG would be to declare that out of scope, but I have not seen evidence the WG wants that restriction.) If so, we need to reach agreement on what we expect of this case, and where it needs to be documented. Yours, Joel M. Halpern PS: Ron has suggested that a HbH optioncould be used to address the inconsistency. I do not yet understand the desired behavior there.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
