| Message ID | 20230731175117.17376-1-andrea.mayer@uniroma2.it (mailing list archive) |
|---|---|
| Headers | show |
| Series | seg6: add NEXT-C-SID support for SRv6 End.X behavior | expand |
On Mon, Jul 31, 2023 at 07:51:15PM +0200, Andrea Mayer wrote: > The NEXT-C-SID mechanism [3] extends the SRv6 architecture by providing several > ways to efficiently represent the SID List. > By leveraging the NEXT-C-SID, is it possible to encode several SRv6 segments > within a single 128 bit SID address (also referenced as Compressed SID > Container). In this way, the length of the SID List can be drastically reduced. nit: it is possible...
In the Segment Routing (SR) architecture a list of instructions, called segments, can be added to the packet headers to influence the forwarding and processing of the packets in an SR enabled network. Considering the Segment Routing over IPv6 data plane (SRv6) [1], the segment identifiers (SIDs) are IPv6 addresses (128 bits) and the segment list (SID List) is carried in the Segment Routing Header (SRH). A segment may correspond to a "behavior" that is executed by a node when the packet is received. The Linux kernel currently supports a large subset of the behaviors described in [2] (e.g., End, End.X, End.T and so on). In some SRv6 scenarios, the number of segments carried by the SID List may increase dramatically, reducing the MTU (Maximum Transfer Unit) size and/or limiting the processing power of legacy hardware devices (due to longer IPv6 headers). The NEXT-C-SID mechanism [3] extends the SRv6 architecture by providing several ways to efficiently represent the SID List. By leveraging the NEXT-C-SID, is it possible to encode several SRv6 segments within a single 128 bit SID address (also referenced as Compressed SID Container). In this way, the length of the SID List can be drastically reduced. The NEXT-C-SID mechanism is built upon the "flavors" framework defined in [2]. This framework is already supported by the Linux SRv6 subsystem and is used to modify and/or extend a subset of existing behaviors. In this patchset, we extend the SRv6 End.X behavior in order to support the NEXT-C-SID mechanism. In details, the patchset is made of: - patch 1/2: add NEXT-C-SID support for SRv6 End.X behavior; - patch 2/2: add selftest for NEXT-C-SID in SRv6 End.X behavior. From the user space perspective, we do not need to change the iproute2 code to support the NEXT-C-SID flavor for the SRv6 End.X behavior. However, we will update the man page considering the NEXT-C-SID flavor applied to the SRv6 End.X behavior in a separate patch. Comments, improvements and suggestions are always appreciated. Thank you all, Andrea [1] - https://datatracker.ietf.org/doc/html/rfc8754 [2] - https://datatracker.ietf.org/doc/html/rfc8986 [3] - https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression Andrea Mayer (1): seg6: add NEXT-C-SID support for SRv6 End.X behavior Paolo Lungaroni (1): selftests: seg6: add selftest for NEXT-C-SID flavor in SRv6 End.X behavior net/ipv6/seg6_local.c | 108 +- tools/testing/selftests/net/Makefile | 1 + .../net/srv6_end_x_next_csid_l3vpn_test.sh | 1213 +++++++++++++++++ 3 files changed, 1302 insertions(+), 20 deletions(-) create mode 100755 tools/testing/selftests/net/srv6_end_x_next_csid_l3vpn_test.sh