Hi Alvaro, > Given that the issue is constrained to an SR domain
The issue seems much more constrained that that. * It seems very clear that there is no issue if we encapsulate packets with new IPv6 header to make it SRv6 * It seems that the issue is also non existent if SRv6 end hosts add an IPv6 encapsulation The only case there is seems to be an "issue" is when SRv6 host - belonging to a SRv6 domain - starts talking SRv6 natively without encapsulation using more then one uSIDs as part of the destination address. Do we have agreement on the scope of the "issue" ? Thx, r. On Mon, Mar 25, 2024 at 7:17 PM 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). > > 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
