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

[Francois Clad <[e-mail]>]

 Hi Joel,

The current text of section 9.1 says:

"When pinging a SID of this document without a segment list, the SR source
node places the SID in the destination address of the ICMPv6 echo request
and MUST set the Argument of the SID to 0. [...]"

"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.”

It seems to me that the two cases are explicitly spelled out.

If I understand correctly, the system that you are referring to is steering
traffic onto a segment list. Diagnostic packets should thus be handled in
the same way (2nd case above). From a user perspective, the diagnostic
tools (e.g., ping) are used with a compressed SRv6 SID-list in the same
that they are used with any other SRv6 SID-list.

Cheers,
Francois

On 4 Apr 2024 at 23:17:53, Joel Halpern <[e-mail]> wrote:

> <No Hats>
>
> A uSID container is a list of destination.  It can  e specified as a DA
> without an SRH.  If I had a sysstme which was using that, and I was
> having trouble, trying a ping with the uSID container as the DA would
> seem to be an obvious diagnostic.   If we want to tell folks they cabn't
> do that, it seems like we need to say so. The existing text Francois
> points to seems too vague to expect folks to understand the limitation
> (assuming there is such a limitation.)
>
> Yours,
>
> Joel
>
> On 4/4/2024 2:47 PM, Martin Vigoureux (Nokia) wrote:
>
> 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
>
>
> _______________________________________________
>
> spring mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/spring
>
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>