On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana <aretana.i...@gmail.com> wrote: > > 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).
Alvaro,. This wouldn't be robust and would seem to violate the "be conservative in what you send clause". Punting this to the operators doesn't seem practical either, in an even moderately large network they wouldn't be able to know all the potential problems they might hit in devices. They're about one misconfiguration away from having to debug a rather unpleasant problem. For instance, if operator gets a packet trace from a router they would see a whole bunch of packets with bad checksums, but they would have no way of knowing if these were cases of segment routing or actually corrupted packets. Tom > > 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
