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

[Robert Raszuk <[e-mail]>]

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.

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
>>> --------------------------------------------------------------------
>>>
>>