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 <jmh.dir...@joelhalpern.com> 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 <jmh.dir...@joelhalpern.com> > 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 <andrew-i...@liquid.tech> >> <andrew-i...@liquid.tech> 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 <spring-boun...@ietf.org> on >>> behalf of Francois Clad <fclad.i...@gmail.com> >>> *Date: *Thursday, 4 April 2024 at 14:49 >>> *To: *Joel Halpern <jmh.dir...@joelhalpern.com> >>> *Cc: *SPRING WG List <spring@ietf.org>, Robert Raszuk <rob...@raszuk.net >>> > >>> *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 >>> fclad.i...@gmail.com. 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 <jmh.dir...@joelhalpern.com> >>> 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 <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 >>> >>>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
