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