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
<http://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 <fclad.i...@gmail.com>
> Date: 4/4/24 1:10 PM (GMT-05:00)
> To: Joel Halpern <jmh.dir...@joelhalpern.com>
> Cc: SPRING WG List <spring@ietf.org>, Robert Raszuk
> <rob...@raszuk.net>, Andrew Alston - IETF <andrew-i...@liquid.tech>
> 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 <jmh.dir...@joelhalpern.com
> <mailto: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> 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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
