Hi Alvaro, I have some concerns about the second paragraph of your email. Compressed SRv6 SIDs (C-SID) are still SRv6 and therefore everything from existing SRv6 RFCs apply and those aspects are very much foundational to this C-SID document as well.
RFC8754 has introduced the omission of SRH (sec 4.1) and reduced SRH behavior (sec 4.1.1) when not required. When taken along with RFC8986 (H.Encap.*) and the most common use-cases for BGP services (RFC9252) where for many scenarios (best effort or flex algo) SRH is not needed. This is something that is already widely deployed by operators around the world in production networks. Mandating SRH, when one is not required, compromises compression efficiency without bringing any advantages. The presence of SRH is never a necessary or sufficient criterion for identification of "SRv6 packets" in any SRv6 related RFC - perhaps this may not be evident to some folks that are not closely following SRv6. Even when SRH is encoded by the SR Source Node, it can be removed by Segment Endpoint Node when using PSP flavors per RFC8986. The base SRv6 RFCs, therefore, refer to allocation of SRv6 SIDs from within an SRv6 SID block and use that for identification (e.g., filtering for security purposes in RFC8754 ) of traffic flows being steered using SRv6 SIDs. Finally, regarding the so-called "issue" related to the upper layer checksum validation by transit nodes. Here, I will say that those nodes need to be SRv6/C-SID (or, in general, any RH) aware for doing such checksum validation - the presence or absence of SRH makes zero difference. I've responded in more detail on the other thread on this. Thanks, Ketan On Thu, Mar 28, 2024 at 5:36 PM 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 > -------------------------------------------------------------------- >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
