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
