Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

2024-04-05 Thread Francois Clad
Hi Andrew, The originator of an IPv6 packet with a SID in its destination address is an SR source node per RFC 8754. If this SID is one of draft-ietf-spring-srv6-srh-compression, then the node must follow the SR source node specification in section 6 of this document. I am curious to know which

[spring] Clarifications for draft-karboubi-spring-sidlist-optimized-cs-sr-00.txt

2024-04-05 Thread Karboubi, Amal
Hello, We have presented draft https://datatracker.ietf.org/doc/draft-karboubi-spring-sidlist-optimized-cs-sr/ [datatracker.ietf.org]

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

2024-04-05 Thread Martin Vigoureux (Nokia)
Le 2024-04-05 à 16:30, Tom Herbert a écrit : CAUTION:This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. On Fri, Apr 5, 2024, 8:53 AM Antoine FRESSANCOURT

Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

2024-04-05 Thread Joel Halpern
Thanks for catching the typo. I am trying to understand what the text in the draft means about originating hosts sending SRv6 packets with (direct or indirectly specified) compressed containers. Yours, Joel On 4/5/2024 10:41 AM, Robert Raszuk wrote: Joel, > a host in an SRv6 domain must n

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

2024-04-05 Thread Robert Raszuk
Tom, So let me try to restate your point. You are saying that such ability to distinguish non encapsulated SR packet with uSIDs is needed only for devices which would capture some packets in the middle, trying to run checksum and failing. Is this so ? Are there any other reasons for this ? I a

Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

2024-04-05 Thread Robert Raszuk
Joel, > a host in an SRv6 domain must not have explicitly configured uSID containers I presume you wanted to say instead "not have" - "now have" And if so I think it applies only to segment endpoints and only such segment endpoint must know his own uSID isn't it ? Is there any reason to that su

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

2024-04-05 Thread Tom Herbert
On Fri, Apr 5, 2024, 8:53 AM Antoine FRESSANCOURT wrote: > Hello, > > After reading RFC 8754 and RFC 8986 together with the draft (version 14), > it seems to me that the cases when the SRH will be omitted are quite > limited, and will happen among nodes sharing the same locator block. We can > as

Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

2024-04-05 Thread Joel Halpern
I think I understand your description.  At base, I think you are arguing that a compresssed container should be understood to be a representation of a segment list.  As a corollary of that, you are saying that the text in 9.1 means that a host in an SRv6 domain must not have explicitly confi

Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

2024-04-05 Thread Antoine FRESSANCOURT
Hello, Regarding the computation of the L4 checksum with C-SIDs, I think the text in section 6.5 is clear enough, and I would not modify the text as it appears in version 14 of the draft. It is very clear that the L4 checksum is computed using the destination address seen by the destination.

Re: [spring] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

2024-04-05 Thread Antoine FRESSANCOURT
Hello, After reading RFC 8754 and RFC 8986 together with the draft (version 14), it seems to me that the cases when the SRH will be omitted are quite limited, and will happen among nodes sharing the same locator block. We can assume that, in such cases, nodes exchanging packets carrying a C-SID

Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

2024-04-05 Thread Tal Mizrahi
Hi, I believe that Section 6.5 is sufficient as-is. Note that I have raised my concerns about the L4 checksum issue in previous versions of the draft, and I believe the current text in Section 6.5 resolves my concerns. Regarding the middlebox discussion, I have not seen (please correct me if I am

Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

2024-04-05 Thread Francois Clad
Hi Joel, The current text of section 9.1 says: "When pinging a SID of this document without a segment list, the SR source node places the SID in the destination address of the ICMPv6 echo request and MUST set the Argument of the SID to 0. [...]" "When pinging a SID of this document via a segmen

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

2024-04-05 Thread Tal Mizrahi
On Thu, Apr 4, 2024 at 2:50 PM Francois Clad wrote: > An SRv6-unaware middlebox will not be able to verify the upper-layer checksum > of SRv6 packets in flight, regardless of whether an SRH is present or not. > An SRv6 and C-SID aware middlebox will be able to find the ultimate DA and > verify t