I can not speak to the "norm" for other working groups. The SPRING
charter is very specific about what we have to do if we want to change
an underlying protocol. We have to go back to the WG which owns that
protocol.
6man gets to decide if the change is acceptable, and if it is acceptable
how it is to be represented. SPRINGs job is to make sure we are asking
the question we intend.
Yours,
Joel
On 4/3/2024 6:05 PM, Robert Raszuk wrote:
Ok Joel,
Thank you for this clarification.
To me the actual spirit of RFC8200 8.1 is to say that it is ok to
compute the checksum by the src such that it comes out right at the
final destination.
But I guess we can have different opinions about that.
But what I find specifically surprising here is that it is a norm in
IETF to have new specifications defining protocol extensions and their
behaviour and never go back to the original protocol RFC to check if
this is ok or not. If that would not be a normal process I bet we
would still be using classful IPv4 routing all over the place.
Regards,
Robert
On Wed, Apr 3, 2024 at 11:28 PM Joel Halpern <j...@joelhalpern.com> wrote:
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
