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

[Mark Smith <[e-mail]>]

Hi Ketan,

On Tue, 9 Apr 2024, 01:55 Ketan Talaulikar, <[e-mail]> wrote:

> 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.
>

I don't think compression efficiency is a valid argument compared to the
drawbacks.

When IPv6 was first published in 1995, in RFC 1883, the highest specified
802.3/Ethernet standard was 100 Mpbs.

Today it is 800 Gbps.

If removing the SRH makes a useful efficiency gain, then the IPv6 40 octet
header itself must be too heavy for SR.

(Which I think it is, otherwise the C-SID hack on the IPv6 Destination
Address field wouldn't be being standardised as a workaround to the
fundamentally unnecessarily too large, IPv6 address derived, 128 bit SIDs.)



>
> 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.
>

You have not mentioned any IPv6 RFCs.

RFC8200 specifies explicit upper layer protocol identification in the Next
Header field of the fixed header or in EHs' Next Header fields.

Regarding filtering using the SID prefix, realise for some operators that
isn't just perhaps 100s or maybe 1000s of packet filter deployments, it can
literally be millions for operators with residential broadband customers.

If SRv6 is considered a separate derivative protocol of IPv6, rather than a
use of IPv6, then you wouldn't have to include the SRH when the IPv6 DA
holds that information, and it would be given its own Ethernet type, saving
some operators literally millions of IPv6 packet filter deployments.


Regards,
Mark.



> 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 <[e-mail]>
> 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
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>