(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 <t...@herbertland.com> wrote:
On Mon, Mar 25, 2024 at 9:40 AM Robert Raszuk <rob...@raszuk.net>
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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
