The concern with regard to the text that the chairs are asking about is
not about intermediate nodes verifying the checksum. The text does not
talk aabout that, so we are not asking about that.
But, the text in 8200 specifies how the originating node is to compute
the upper layer checksum. It doesn't say "do whatever you need to do to
make the destination come out right". It provides specific
instructions. Yes, it is understandable that those instructions do not
cover the compressed container cases. Which is why the compression
document specifies changes to those procedures.
Thus, we need to ask 6man how they want to handle the change in the
instructions in 8200.
the question we are asking SPRING is whether there is any clarification
people want to the text in the compression draft before we send the
question over to 6man.
Yours,
Joel
On 4/3/2024 5:15 PM, Robert Raszuk wrote:
Hi Joel,
My interpretation of text from RFC8200 is that it allows discrepancy
between the header and the upper layer checksum as long as final
packet's destination sees the correct one.
The last condition is met.
So I see no issue.
Sure RFC8200 does not talk about SRH nor cSIDs, but provides a hint on
how to handle such future situations.
With that being said I would like to still understand what real
problem are we hitting here ...
Kind regards,
Robert
On Wed, Apr 3, 2024 at 11:09 PM Joel Halpern <j...@joelhalpern.com> wrote:
There are two cases covered in section 6.5 of the compression
draft that appear to be at variance with secton 8.1 of RFC 8200.
First, if the final destination in the routing header is a
compressed container, then the ultimate destination address will
not be the same as the final destination shown in the routing header.
Second, if a uSID container is used as the destination address and
no SRH is present, then in addition to the above problem there is
no routing header to trigger the behavior described.
Yours,
Joel
On 4/3/2024 4:22 PM, Robert Raszuk wrote:
Hi Alvaro,
Section 6.5 of draft-ietf-spring-srv6-srh-compression
describes the
behavior when an originating node inside an SRv6 domain creates a
packet with a C-SID as the final destination. _This
description differs
from the text in Section 8.1 of RFC8200._
I would like you to clarify the above statement - specifically of
the last sentence.
Reason for this that after looking at both drafts I find section
6.5 of the subject draft to be exactly in line with RFC8200
section 8.1 especially with the paragraf which says:
* 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.
*
So before we dive into solutions (as Andrew has already provided
a few of) I think we should first agree on what precise problem
are we solving here ?
Many thx,
Robert
PS. As a side note I spoke with my hardware folks - just to check
if validation of upper-layer checksum is even an option for
transit nodes. The answer is NO as most data plane hardware can
read at most 256 bytes of packets. So unless there is some
specialized hardware processing up to 9K packets in hardware at
line rates this entire discussion about checksum violations,
fears of firing appeals is just smoke.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
