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

[Tom Herbert <[e-mail]>]

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