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

[Robert Raszuk <[e-mail]>]

Well software could know that but not NICs nor ASICs ...

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

>
>
> On Thu, Apr 4, 2024, 4:00 PM Robert Raszuk <[e-mail]> wrote:
>
>> Tom,
>>
>> I have full sympathy for your points.
>>
>> But I can not understand how suddenly SR uSID is the issue and normal
>> IPv6 vanilla Routing Headers are ok as defined checksum wise in RFC8200.
>>
>> Maybe someone could elaborate a bit on that ?
>>
>
> Robert,
>
> Because, when a routing header is present we know that the final address
> in the list is the one to used as the destination address in the pseudo
> header. If the last address is uncompressed or can be decompressed without
> additional state then we can calculate the checksum based on that (also,
> that allows us to track flows in the network which is another useful thing
> in a data center).
>
> Tom
>
>
>> Thx,
>> R.
>>
>> PS. And of course in spite of all effort from Alvaro to sort the topics
>> the threads again got completely mangled and everyone is describing their
>> perceived issue in random thread. My gently hint for the chairs would be to
>> log issues in github and have more structured processing them there.
>>
>>
>>
>> On Thu, Apr 4, 2024 at 9:50 PM Tom Herbert <[e-mail]> wrote:
>>
>>>
>>>
>>> On Thu, Apr 4, 2024, 3:37 PM Ole Trøan <otroan=
>>> [e-mail]> wrote:
>>>
>>>> Tom,
>>>>
>>>> Can you point to any IETF specification requiring that middle boxes
>>>> should be able to validate a l4 checksum? IPsec be damn.  It just seems
>>>> like a path we should not go down.
>>>>
>>>
>>> Ole,
>>>
>>> No, but neither can I point to an RFC that says firewalls have to parse
>>> deep into packets. The point is that we know people can and do such things
>>> (packet traces and checksum offload are deployed use cases for this).
>>>
>>> The transport checksum has been maintained to be correct on the wire in
>>> plain UDP,TCP/IPv6 for thirty years even in NAT. Breaking that convention
>>> without considering the ramifications could very well lead to some
>>> unhappiness. And my concern is that problems would not just be confined to
>>> SR packets, but could affect non-SR (like how we debug checksum problems in
>>> non-SR traffic).
>>>
>>> Tom
>>>
>>>
>>>> O.
>>>>
>>>>
>>>>
>>>> On 4 Apr 2024, at 21:22, Tom Herbert <tom=
>>>> [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
>>>>>>>> --------------------------------------------------------------------
>>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>>
>>>>