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
