Re: [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

[Robert Raszuk <[e-mail]>]

Show me Broadcom's SDK which does this in DNX family and we can talk more
about such option.

Best,
R.

On Thu, Apr 4, 2024 at 9:22 PM Tom Herbert <[e-mail]> wrote:

>
>
> On Thu, Apr 4, 2024, 3:12 PM Robert Raszuk <[e-mail]> wrote:
>
>> Tom,
>>
>> >  SR aware routers to update L4 checksum
>>
>> That is completely unrealistic.
>>
>> Show me the box which can forward all interfaces at 800 Gb/s and read
>> entire each packet and compute upper layer checksum on it.
>>
>
> Robert,
>
> It's not necessary to calculate the whole checksum, only the L4 checksum
> needs to be updated by adding in the delta checksum. With IPv6 we can also
> do a checksum neutral mapping. Basically, this uses the low order 16 bits
> in the DA address as the checksum adjustment value. For instance, if we can
> use the low order bits in a SID block then that would be simplest to
> implement.
>
> Tom
>
>
>> If anything just do encap and move on.
>>
>> Thx,
>> R.
>>
>>
>> On Thu, Apr 4, 2024 at 7:06 PM Tom Herbert <[e-mail]> wrote:
>>
>>>
>>>
>>> On Thu, Apr 4, 2024, 12:30 PM Robert Raszuk <[e-mail]> wrote:
>>>
>>>> Hi Tom,
>>>>
>>>> Yes I am with you here.
>>>>
>>>> However let's observe that this is pretty common best practice to
>>>> disable any hardware offload on the box when running tcpdump or wireshark.
>>>>
>>>> In fact some implementations (F5) do it for you automagically :)
>>>>
>>>> And as it has been said based on the fact that hardware offload does
>>>> not understand any Routing Headers it really does not matter if it is there
>>>> or not :)
>>>>
>>>
>>> Robert,
>>>
>>> tcpdump is independent of hardware offload. If the checksum is incorrect
>>> per the packet contents we'll see bad checksums reported if we snoop
>>> packets, but like I said, we can't differentiate the bad from the good.
>>>
>>> Offload becomes an issue for NICs that do protocol specific checksum
>>> offload. We lose the capability on RX which is an inconvenience, on TX we'd
>>> need to change the implementation to ensure the checksum is not computed by
>>> HW.
>>>
>>> If SR without SRH is needed, then I believe the best answer is for SR
>>> aware routers to update L4 checksum when they change DA per NAT
>>> requirements. This solves tcpdump as well as offloads.
>>>
>>> Tom
>>>
>>>
>>>> Cheers,
>>>> R.
>>>>
>>>>
>>>> On Thu, Apr 4, 2024 at 6:11 PM Tom Herbert <tom=
>>>> [e-mail]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Apr 4, 2024, 11:48 AM Francois Clad <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Hi Tom,
>>>>>>
>>>>>> Tcpdump can determine that this packet is steered onto an SRv6 path
>>>>>> by checking if the DA matches the SRv6 SID block.
>>>>>>
>>>>>
>>>>> Francois,
>>>>>
>>>>> That would require introducing external state to tcpdump for correct
>>>>> operation. This would be a major divergence in both implementation and ops
>>>>> compared to how things work today.
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>> Francois
>>>>>>
>>>>>> On 4 Apr 2024 at 16:59:59, Tom Herbert <[e-mail]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Apr 4, 2024, 9:39 AM Francois Clad <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Mark,
>>>>>>>>
>>>>>>>> Tcpdump/wireshark decodes the IPv6 header just fine. I do not see
>>>>>>>> any issue here.
>>>>>>>>
>>>>>>>
>>>>>>> Francois,
>>>>>>>
>>>>>>> The problem is that tcpdump can't tell that a packet is an SR packet
>>>>>>> if there's no SRH. For instance, if the checksum is not maintained to be
>>>>>>> correct in the wire then tcpdump will show that the packet has a bad L4
>>>>>>> checksum, but there's no way to tell if that is an SR packet or if the
>>>>>>> checksum is actually bad. This will make debugging checksum failures in the
>>>>>>> network much more difficult, and this affects our ability to debug all
>>>>>>> traffic not just SR packets.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Francois
>>>>>>>>
>>>>>>>> On 4 Apr 2024 at 14:09:43, Mark Smith <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, 4 Apr 2024, 22:50 Francois Clad, <[e-mail]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Alvaro, all,
>>>>>>>>>>
>>>>>>>>>> RFC 8754 allows the SR source node to omit the SRH when it
>>>>>>>>>> contains redundant information with what is already carried in the base
>>>>>>>>>> IPv6 header. Mandating its presence for C-SID does not resolve any problem
>>>>>>>>>> because it will not provide any extra information to the nodes along the
>>>>>>>>>> packet path.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> How are troubleshooting tools like 'tcpdump' going to know how to
>>>>>>>>> automatically decode these packets as SRv6 packets if there is no SRH?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Specifically for the case of middleboxes attempting to verify the
>>>>>>>>>> upper-layer checksum,
>>>>>>>>>>
>>>>>>>>>>    - An SRv6-unaware middlebox will not be able to verify the
>>>>>>>>>>    upper-layer checksum of SRv6 packets in flight, regardless of whether an
>>>>>>>>>>    SRH is present or not.
>>>>>>>>>>    - An SRv6 and C-SID aware middlebox will be able to find the
>>>>>>>>>>    ultimate DA and verify the upper-layer checksum in flight, regardless of
>>>>>>>>>>    whether an SRH is present or not.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Furthermore, transit nodes (e.g., middleboxes) should not attempt
>>>>>>>>>> to identify SRv6 traffic based on the presence of the SRH, because they
>>>>>>>>>> will miss a significant portion of it: all the best-effort or Flex-Algo
>>>>>>>>>> traffic steered with a single segment may not include an SRH, even without
>>>>>>>>>> C-SID. Instead, RFC 8402, 8754, and 8986 define identification rules based
>>>>>>>>>> on the SRv6 SID block.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Francois
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2 Apr 2024 at 19:44:51, Alvaro Retana <[e-mail]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> [Moving this conversation up on your mailbox. :-) ]
>>>>>>>>>>>
>>>>>>>>>>> [Thanks, Robert and Tom for your input!]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> We want to hear from more of you, including the authors. Even if
>>>>>>>>>>> you already expressed your opinion in a different thread, please chime in
>>>>>>>>>>> here.
>>>>>>>>>>>
>>>>>>>>>>> We will collect feedback until the end of this week.
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>> Alvaro.
>>>>>>>>>>>
>>>>>>>>>>> On March 28, 2024 at 8:06:18 AM, Alvaro Retana (
>>>>>>>>>>> [e-mail]) wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Focusing on the C-SID draft, some have suggested requiring the
>>>>>>>>>>> presence of the SRH whenever C-SIDs are used. Please discuss whether that
>>>>>>>>>>> is the desired behavior (or not) -- please be specific when debating the
>>>>>>>>>>> benefits or consequences of either behavior.
>>>>>>>>>>>
>>>>>>>>>>> Please keep the related (but independent) discussion of
>>>>>>>>>>> requiring the SRH whenever SRv6 is used separate. This larger topic may
>>>>>>>>>>> impact several documents and is better handled in a different thread (with
>>>>>>>>>>> 6man and spring included).
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>> Alvaro
>>>>>>>>>>> -- for spring-chairs
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>>>> IETF IPv6 working group mailing list
>>>>>>>>>>> [e-mail]
>>>>>>>>>>> Administrative Requests:
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>>>>
>>>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>>> IETF IPv6 working group mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> Administrative Requests:
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>>>
>>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> --------------------------------------------------------------------
>>>>>>>> IETF IPv6 working group mailing list
>>>>>>>> [e-mail]
>>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>> --------------------------------------------------------------------
>>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> [e-mail]
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>>>>
>>>>