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

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.ietf@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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>