[spring] Re: [IPv6]6MAN Chairs conclusions on Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Tom Herbert <tom@herbertland.com> Wed, 03 July 2024 16:47 UTC

MIME-Version: 1.0
References: <BD958D15-F596-4D14-AED2-5B616FA11430@gmail.com>
In-Reply-To: <BD958D15-F596-4D14-AED2-5B616FA11430@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 03 Jul 2024 09:47:34 -0700
Message-ID: <CALx6S35ZG8YmS4zYNgJUCY=WzufDujEwHBiminrqs7xguqk9HQ@mail.gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: N3ZNF6BI27RSJ6WT7XFQ3Y4ODHY3RMSL
CC: Alvaro Retana <aretana.ietf@gmail.com>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, SPRING WG List <spring@ietf.org>, IPv6 List <ipv6@ietf.org>
Precedence: list
Subject: [spring] Re: [IPv6]6MAN Chairs conclusions on Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/xg699HqpZL_V1Tv9NKA0oI65MDU>

On Wed, Jul 3, 2024 at 9:35 AM Bob Hinden <bob.hinden@gmail.com> wrote:
>
> Alvaro, Spring Chairs,
>
> The 6MAN chairs have reviewed the discussion on your query to the IPv6 list.   This is our thoughts.
>
> Process wise we don’t think we can declare any kind of formal consensus on this.   We are sure you have also read the discussion.  We do have some feedback from our reading of the discussion.
>
> Our read is there is a number of people who don’t like using C-SIDs due to issues relating to verify transport checksums due to not having access to final destination address.   We don’t think this is a significant issue as long as they are in a SRH header.  That provides additional context that C-SIDs may be in use.
>
> We think there is a stronger issue when using C-SIDs without a SRH header.   There isn’t any context for knowing how to handle these packets.   We also agree with the point was that for an endpoint, there would be no way for that endpoint to do hardware offload for the TCP checksum.  Even if the NIC supported SRH it would not know how to restore the original destination address.  These NICs commonly fail to do TCP offload with any routing header or other extension headers too, so the failure is there.  It is made worse without having any context that C-SIDs are being used.
>
> We think this issue could be reduced if there was a way to identify that the packets contained C-SIDs.  For example, if they were using the prefix defined in <draft-ietf-6man-sids>.  We note that <draft-ietf-spring-srv6-srh-compression> does reference this prefix defined in <draft-ietf-6man-sids>, but does not require its use.
>

Bob,

The prefix would need to be defined as a standard code point, but even
so it would be complex to implement in offloads and still wouldn't be
compatible with protocol specific checksum offloads. Additionally,
then we'd have to update all network devices that might want to look
at the checksum in flight to understand the prefix. I don't think it's
a feasible solution.

How about recommending doing a checksum-neutral mapping like in RFC
6296 where instead of affecting the source address, manipulate bits in
the destination address?

Tom

> Bob, Ole, Jen
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests:
> --------------------------------------------------------------------

[spring] 6MAN Chairs conclusions on Mandating SRH… Bob Hinden
[spring] Re: [IPv6]6MAN Chairs conclusions on Man… Tom Herbert