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 >>> -------------------------------------------------------------------- >>> >>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
