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

[Francois Clad <[e-mail]>]

 Hi Tom,

Tcpdump can determine that this packet is steered onto an SRv6 path by
checking if the DA matches the SRv6 SID block.

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