Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Alvaro Retana <[e-mail]>]

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 ([e-mail]) 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.