Hi Joel, Yes, I believe your suggestion is the best approach, i.e., to integrate an adaptation of the text from draft-mizrahi-spring-l4-checksum-srv6 into the compression draft. I would be happy to help the authors with that.
Cheers, Tal. On Thu, Aug 3, 2023 at 6:50 PM Joel Halpern <j...@joelhalpern.com> wrote: > > You make a good point about SRH already being covered but the corner > case with compression not being covered. > > Speaking personally, I would expect that to be dealt with by including > the relevant text in the compression draft, and noting that it updates > 8200 (which probably means the last call needs to go to both groups, but > that is easily done.) > > Do you see a problem with teh compression editors starting from the text > in your draft to create a fix in the compression document? > > Do you want an issue opened to track this? (If so, go ahead and open > one please.) > > Yours, > > Joel > > On 8/3/2023 2:54 AM, Tal Mizrahi wrote: > > Hi Joel, > > > > I agree that this may be a corner case, but it still needs to be covered. > > As you pointed out, the compression document should certainly mention > > how the checksum computation is affected by the compression. > > > > There are two main issues with the text in [RFC8200]. The first is > > that the following sentence is no longer correct: "... the Destination > > Address used in the pseudo-header is that of the final destination. > > At the originating node, that address will be in the last element of > > the Routing header". The second issue is that the text in [RFC8200] > > currently does not cover the case where SRv6 is used without an SRH. > > > > I believe that the first issue requires an update to [RFC8200], > > because otherwise it contradicts the compression document. The second > > issue, in my opinion, should be updated in [RFC8200] to avoid > > confusion, and it is pretty straightforward if we are already updating > > this paragraph regarding the first issue. > > > > > >> Probably. Please suggest text. > > Sure. > > I have summarized the problem and my suggestion of how to address it > > in the following new draft: > > https://datatracker.ietf.org/doc/draft-mizrahi-spring-l4-checksum-srv6/ > > > > As suggested, I am opening a separate thread that includes SPRING and 6MAN. > > > > Cheers, > > Tal. > > > > > > On Wed, Aug 2, 2023 at 4:52 PM Joel Halpern <j...@joelhalpern.com> wrote: > >> Speaking personally, not as chair. > >> > >> As far as I know, there is no need for an update to 8200 for this > >> quasi-problem. > >> > >> Let's state the problem with or without SRH. > >> > >> If two trusted hosts inside a trusted domain that uses SRv6 are > >> communicating, and the path they wish to select has more than one hop, > >> then when the sending host computes the upper layer checksum, it has to > >> use the eventual destination, not the destination with which it will > >> send the packet to the wire. This is true whether SRH is used, whether > >> gSID or uSID are used, or any other technique we invent later. > >> > >> Should this have been better spelled out in RFC 8754? Probably. > >> > >> Should the compression document note that it adds more cases to this? > >> Probably. Please suggest text. > >> > >> Is this a corner case that I personally consider quite rare? Yes, > >> although it was the original excuse for the authentication TLV. > >> > >> Yours, > >> > >> Joel > >> > >> On 8/2/2023 1:58 AM, Tal Mizrahi wrote: > >>> Darren, Authors, Chairs, > >>> > >>> Thanks for the quick response. > >>> > >>> In that case I have two comments: > >>> > >>> 1. I believe that the fact that a compressed segment list can be sent > >>> without an SRH should be explained earlier in the document, i.e., in > >>> the introduction. Actually the title of the draft is a bit misleading. > >>> I would suggest to change it from "Compressed SRv6 Segment List > >>> Encoding in SRH" to simply "Compressed SRv6 Segment List Encoding". > >>> > >>> 2. It appears that there is an issue with the L4 checksum computation > >>> which requires an update to RFC 8200. The L4 checksum is computed > >>> using a pseudo-header which includes the IPv6 addresses. In the case > >>> where a compressed segment list is sent without an SRH, this would > >>> cause an inconsistent L4 checksum computation between the sender and > >>> the receiver (SR ingress and egress nodes). While there is some text > >>> in Section 10.2 of the compression draft that slightly hints to this > >>> problem, there needs to be an explicit update to RFC 8200. > >>> > >>> A question to the chairs: is the L4 checksum issue something that can > >>> be resolved in SPRING, or does it have to go through 6MAN? > >>> > >>> Here is the text I was referring to from [RFC 8200]: > >>> OLD: > >>> If the IPv6 packet contains a Routing header, the Destination > >>> Address used in the pseudo-header is that of the final > >>> destination. At the originating node, that address will be in > >>> the last element of the Routing header; at the recipient(s), > >>> that address will be in the Destination Address field of the > >>> IPv6 header. > >>> > >>> I would propose the following alternative text to [RFC 8200]: > >>> NEW: > >>> If the IPv6 packet contains a Routing header, the Destination > >>> Address used in the pseudo-header is that of the final > >>> destination. At the recipient(s), that address will be in the > >>> Destination Address field of the IPv6 header. At the > >>> originating node, that address will be the Destination > >>> Address as it is expected to be received by the destination. > >>> Note, that if segment list compression > >>> [I-D.ietf-spring-srv6-srh-compression] is used, then the > >>> Destination Address as received by the destination may be > >>> different than the last element of the Routing header. > >>> Similarly, if segment list compression is used without using > >>> the > >>> Routing header, then the Destination Address used in the > >>> pseudo-header is the address that is expected to be received > >>> by the destination. > >>> > >>> Cheers, > >>> Tal. > >>> > >>> On Tue, Aug 1, 2023 at 6:46 PM Darren Dukes (ddukes) <ddu...@cisco.com> > >>> wrote: > >>>> That is correct. > >>>> ________________________________ > >>>> From: spring <spring-boun...@ietf.org> on behalf of Tal Mizrahi > >>>> <tal.mizrahi....@gmail.com> > >>>> Sent: Tuesday, August 1, 2023 4:29 AM > >>>> To: draft-ietf-spring-srv6-srh-compress...@ietf.org > >>>> <draft-ietf-spring-srv6-srh-compress...@ietf.org>; spring@ietf.org > >>>> <spring@ietf.org> > >>>> Subject: [spring] Question regarding > >>>> draft-ietf-spring-srv6-srh-compression > >>>> > >>>> Dear Authors, > >>>> > >>>> I have a question regarding the following two paragraphs from the > >>>> draft (at the bottom of the message). > >>>> If I understand the text correctly, if the compressed segment list > >>>> fits into a single SID, then the entire compressed list can be encoded > >>>> in the DA, and the packet can be sent without an SRH. Note that this > >>>> is specifically relevant with the NEXT-C-SID flavor. > >>>> > >>>> I would highly appreciate if you can confirm my understanding. > >>>> > >>>> Thanks, > >>>> Tal. > >>>> > >>>> > >>>> Quoting the relevant text from the draft: > >>>> > >>>> Regardless of how a compressed segment list is produced, it is encoded > >>>> in the IPv6 header and optional SRH as described in Section 4.1 and > >>>> 4.1.1 of [RFC8754]. The text is reproduced below for reference. > >>>> > >>>> 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. > >>>> > >>>> _______________________________________________ > >>>> 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
