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

["Martin Vigoureux (Nokia)" <[e-mail]>]

Joel,

do you mean specifying the sid *list* as the DA?

-m

Le 2024-04-04 à 19:26, jmh.direct a écrit :
> 	
> CAUTION:This is an external email. Please be very careful when clicking 
> links or opening attachments. See the URL nok.it/ext for additional 
> information.
> 
> So you can't ping a uSID list by just specifying the uSID as the DA?
> Yours,
> Joel
> 
> 
> 
> Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone
> 
> 
> -------- Original message --------
> From: Francois Clad <[e-mail]>
> Date: 4/4/24 1:10 PM (GMT-05:00)
> To: Joel Halpern <[e-mail]>
> Cc: SPRING WG List <[e-mail]>, Robert Raszuk <[e-mail]>, 
> Andrew Alston - IETF <[e-mail]>
> Subject: Re: [spring] C-SIDs and upper layer checksums 
> (draft-ietf-spring-srv6-srh-compression)
> 
> Hi Joel,
> 
> One can ping a SID of this document without a segment list by simply 
> running the ping command with that SID as an argument (2nd paragraph of 
> section 9.1).
> 
> To ping a SID of this document via a SID list, one needs to configure 
> the originator node to impose that SID list, like any other SRv6 SID list.
> 
> Hope this helps.
> 
> Cheers,
> Francois
> 
> 
> On 4 Apr 2024 at 16:29:11, Joel Halpern <[e-mail] 
> <mailto:[e-mail]>> wrote:
>>
>> <No Hats>
>>
>> It seems that the text you quote requires that the ping code or kernel 
>> code know that the user has specified a uSID for the ping DA.   Maybe 
>> I am missing something, but it is not obvious to me how that would be 
>> achieved?  And does seem to imply that an unmodified ping will get 
>> incompatible and unexpected results?
>>
>> Yours,
>>
>> Joel
>>
>> On 4/4/2024 10:23 AM, Francois Clad wrote:
>>> Hi Joel,
>>>
>>> The ping behavior is described in section 9.1 of the draft 
>>> (https://www.ietf.org/archive/id/draft-ietf-spring-srv6-srh-compression-14.html#section-9.1).
>>>
>>> Specifically,
>>> "When pinging a SID of this document via a segment list, the SR 
>>> source node MUST construct the IPv6 packet as described in Section 6 
>>> and compute the ICMPv6 checksum as described in Section 6.5."
>>>
>>> Please let me know if anything in this text is not clear.
>>>
>>> Thanks,
>>> Francois
>>>
>>> On 4 Apr 2024 at 16:10:11, Joel Halpern <[e-mail]> 
>>> wrote:
>>>>
>>>> <No Hat>
>>>>
>>>> Does this mean that if I have a source and destiantion host inside 
>>>> an SRv6 domain, and I am trying to verify a uSID path between them, 
>>>> so I issue the command ping <usUD-DA>, it will fail?  Given that we 
>>>> have documents describing the use of ping and traceroute with SRv6, 
>>>> shouldn't the comrpession document say someething about this?
>>>>
>>>> Your,s
>>>>
>>>> Joel
>>>>
>>>> On 4/4/2024 9:59 AM, Francois Clad wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> The originator (TX Linux box in your case) acting as an SR source 
>>>>> node for C-SID must follow the entire Section 6 of 
>>>>> draft-ietf-spring-srv6-srh-compression, including section 6.5 about 
>>>>> the checksum calculation. One cannot expect it to work if it only 
>>>>> implements half of it.
>>>>>
>>>>> On the receive side, there is nothing special to do. The DA in the 
>>>>> received IPv6 header is the one that was used for the checksum 
>>>>> calculation.
>>>>>
>>>>> I do not see anything broken.
>>>>>
>>>>> Cheers,
>>>>> Francois
>>>>>
>>>>> On 4 Apr 2024 at 15:32:12, Andrew Alston - IETF 
>>>>> <[e-mail]> wrote:
>>>>>>
>>>>>> So in investgiating this further, there is a further problem.
>>>>>>
>>>>>> I’ve checked on 4 different linux boxes with 4 different network 
>>>>>> cards.
>>>>>>
>>>>>> Linux by default offloads TX checksumming on a lot of network 
>>>>>> cards.  If you originate a packet with a microsid and no SRH – and 
>>>>>> the linux box offloads the checksum generation – the checksum 
>>>>>> generated by the NIC will be incorrect – and when the packet 
>>>>>> arrives at the end host – if that end host is running RX 
>>>>>> checksumming – the checksum will fail and the packet will be dropped.
>>>>>>
>>>>>> If you disable TX checksumming – the kernel will have no way to 
>>>>>> tell if the packet is an Ipv6 or a microsid packet, it will 
>>>>>> therefore use the DA – and generate an incorrect checksum.  Again 
>>>>>> – if RX checksumming is enabled on the receiving end point – the 
>>>>>> packet will get dropped.
>>>>>>
>>>>>> Effectively this does NOT just affect middle boxes – it effects 
>>>>>> anything generating a packet directed to a microsid that either 
>>>>>> offloads the tx to hardware (whichi will have no clue this is a 
>>>>>> microsid) or in the alternative is generating tx checksums itself 
>>>>>> via kernel mechanisms that will treat these packets as standard 
>>>>>> Ipv6 packets.
>>>>>>
>>>>>> This is broken – severely broken.
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>> *
>>>>>> *
>>>>>>
>>>>>> *
>>>>>>
>>>>>> Internal All Employees
>>>>>>
>>>>>> From: *spring <[e-mail]> on behalf of Francois Clad 
>>>>>> <[e-mail]>
>>>>>> *Date: *Thursday, 4 April 2024 at 14:49
>>>>>> *To: *Joel Halpern <[e-mail]>
>>>>>> *Cc: *SPRING WG List <[e-mail]>, Robert Raszuk 
>>>>>> <[e-mail]>
>>>>>> *Subject: *Re: [spring] C-SIDs and upper layer checksums 
>>>>>> (draft-ietf-spring-srv6-srh-compression)
>>>>>>
>>>>>> 	
>>>>>>
>>>>>> Some people who received this message don't often get email from 
>>>>>> [e-mail]. Learn why this is important 
>>>>>> <https://aka.ms/LearnAboutSenderIdentification>
>>>>>>
>>>>>> 	
>>>>>>
>>>>>> CAUTION: This email has originated from a free email service 
>>>>>> commonly used for personal email services, please be guided 
>>>>>> accordingly especially if this email is asking to click links or 
>>>>>> share information.
>>>>>>
>>>>>> 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
>>>>>>
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring