Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

[Francois Clad <[e-mail]>]

 Hi all,

Section 6.5 of draft-ietf-spring-srv6-srh-compression specifies how an SR
source node originating a packet with an upper layer checksum determines
the Destination Address for use in the IPv6 pseudo-header.

As a co-author, I’d say that the current text of 6.5 is good.

This text is aligned with RFC 8200. It only indicates how the text in
Section 8.1 of RFC 8200 applies to the SIDs of
draft-ietf-spring-srv6-srh-compression. This is necessary since RFC 8200
does not specify the format nor behavior of any source routing scheme.

Thanks,
Francois


On 4 Apr 2024 at 00:10:55, Joel Halpern <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>