On Thu, Apr 4, 2024, 4:00 PM Robert Raszuk <rob...@raszuk.net> 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 <t...@herbertland.com> wrote: > >> >> >> On Thu, Apr 4, 2024, 3:37 PM Ole Trøan <otroan= >> 40employees....@dmarc.ietf.org> 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= >>> 40herbertland....@dmarc.ietf.org> wrote: >>> >>> >>> >>> >>> On Thu, Apr 4, 2024, 3:12 PM Robert Raszuk <rob...@raszuk.net> 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 <t...@herbertland.com> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Apr 4, 2024, 12:30 PM Robert Raszuk <rob...@raszuk.net> 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= >>>>>> 40herbertland....@dmarc.ietf.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 4, 2024, 11:48 AM Francois Clad <fclad.i...@gmail.com> >>>>>>> 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 <t...@herbertland.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Apr 4, 2024, 9:39 AM Francois Clad <fclad.i...@gmail.com> >>>>>>>>> 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 <markzzzsm...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, 4 Apr 2024, 22:50 Francois Clad, <fclad.i...@gmail.com> >>>>>>>>>>> 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 < >>>>>>>>>>>> aretana.i...@gmail.com> 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 ( >>>>>>>>>>>>> aretana.i...@gmail.com) 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 >>>>>>>>>>>>> i...@ietf.org >>>>>>>>>>>>> Administrative Requests: >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>>>>>> >>>>>>>>>>>>> -------------------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -------------------------------------------------------------------- >>>>>>>>>>>> IETF IPv6 working group mailing list >>>>>>>>>>>> i...@ietf.org >>>>>>>>>>>> Administrative Requests: >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>>>>> >>>>>>>>>>>> -------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -------------------------------------------------------------------- >>>>>>>>>> IETF IPv6 working group mailing list >>>>>>>>>> i...@ietf.org >>>>>>>>>> Administrative Requests: >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>>>> >>>>>>>>>> -------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>> >>>>>>> -------------------------------------------------------------------- >>>>>>> IETF IPv6 working group mailing list >>>>>>> i...@ietf.org >>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> -------------------------------------------------------------------- >>>>>>> >>>>>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> i...@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >>>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
