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

[Joel Halpern <[e-mail]>]

(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.

On 3/25/2024 1:03 PM, Robert Raszuk wrote:
> Hi Tom,
>
> I don't think so, but I admit I may not be aware of some interesting 
> use cases ....
>
> Many thx,
> R.
>
>
> On Mon, Mar 25, 2024 at 5:57 PM Tom Herbert <[e-mail]> wrote:
>
>     On Mon, Mar 25, 2024 at 9:40 AM Robert Raszuk <[e-mail]>
>     wrote:
>     >
>     >
>     > Actually looking at this from the perspective where SRH may be
>     omitted I see in the subject draft this clearly stated:
>     >
>     > A source node steers a packet into an SR Policy. If the SR
>     Policy results in a Segment List containing a single segment, and
>     there is no need to add information to the SRH flag or add TLV;
>     the DA is set to the single Segment List entry, and the SRH MAY be
>     omitted.¶
>     >
>     >
>     > That to me indicated that host computed checksum will be correct
>     all along the transit nodes. So no issue either here.
>     >
>     > Could someone illustrate with a drawing of packet's traversing
>     the network their assumed header format and forseen issues ?
>
>     Robert,
>
>     Are there any cases in segment routing where the Destination Address
>     is changed in flight and a routing header is not present in the
>     packet?
>
>     Tom
>
>     >
>     > Thx,
>     > R,
>     >
>
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring