| Message ID | 20220912171619.16943-1-andrea.mayer@uniroma2.it (mailing list archive) |
|---|---|
| Headers | show |
| Series | seg6: add NEXT-C-SID support for SRv6 End behavior | expand |
Hello: This series was applied to netdev/net-next.git (master) by Paolo Abeni <pabeni@redhat.com>: On Mon, 12 Sep 2022 19:16:16 +0200 you wrote: > The Segment Routing (SR) architecture is based on loose source routing. > 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. > In SRv6 (Segment Routing over IPv6 data plane) [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). > > [...] Here is the summary with links: - [net-next,v2,1/3] seg6: add netlink_ext_ack support in parsing SRv6 behavior attributes https://git.kernel.org/netdev/net-next/c/e2a8ecc45165 - [net-next,v2,2/3] seg6: add NEXT-C-SID support for SRv6 End behavior https://git.kernel.org/netdev/net-next/c/848f3c0d4769 - [net-next,v2,3/3] selftests: seg6: add selftest for NEXT-C-SID flavor in SRv6 End behavior https://git.kernel.org/netdev/net-next/c/19d6356ab3f0 You are awesome, thank you!
The Segment Routing (SR) architecture is based on loose source routing. 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. In SRv6 (Segment Routing over IPv6 data plane) [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). Some SRv6 scenarios (i.e.: traffic-engineering, fast-rerouting, VPN, mobile network backhaul, etc.) may require a large number of segments (i.e. up to 15). Therefore, reducing the size of the SID List is useful to minimize the impact on MTU (Maximum Transfer Unit) and to enable SRv6 on legacy hardware devices with limited processing power that can suffer from long IPv6 headers. Draft-ietf-spring-srv6-srh-compression [3] extends the SRv6 architecture by providing different mechanisms for the efficient representation (i.e. compression) of the SID List. The NEXT-C-SID mechanism described in [3] offers the possibility of encoding several SRv6 segments within a single 128 bit SID address. Such a SID address is called a Compressed SID Container. In this way, the length of the SID List can be drastically reduced. In some cases, the SRH can be omitted, as the IPv6 Destination Address can carry the whole Segment List, using its compressed representation. The NEXT-C-SID mechanism relies on the "flavors" framework defined in [2]. The flavors represent additional operations that can modify or extend a subset of the existing behaviors. In this patchset we extend the SRv6 Subsystem in order to support the NEXT-C-SID mechanism. In details the patchset is made of: - patch 1/3: add netlink_ext_ack support in parsing SRv6 behavior attributes; - patch 2/3: add NEXT-C-SID support for SRv6 End behavior; - patch 3/3: add selftest for NEXT-C-SID in SRv6 End behavior. The corresponding iproute2 patch for supporting the NEXT-C-SID in SRv6 End behavior is provided in a separated patchset. 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 v1 -> v2: - rename misleading variable names and macros, using the suffix '_bits' instead of '_len', e.g. 'lcblock_len'->'lcblock_bits'; - remove unnecessary cast operations; - get rid of the 'yoda-style' syntax; - fix check for default C-SID configuration at compilation time; - add selftest for NEXT-C-SID in SRv6 End behavior. Thanks to Paolo Abeni for reviewing v1. Andrea Mayer (3): seg6: add netlink_ext_ack support in parsing SRv6 behavior attributes seg6: add NEXT-C-SID support for SRv6 End behavior selftests: seg6: add selftest for NEXT-C-SID flavor in SRv6 End behavior include/uapi/linux/seg6_local.h | 24 + net/ipv6/seg6_local.c | 379 +++++- tools/testing/selftests/net/Makefile | 1 + .../net/srv6_end_next_csid_l3vpn_test.sh | 1145 +++++++++++++++++ 4 files changed, 1530 insertions(+), 19 deletions(-) create mode 100755 tools/testing/selftests/net/srv6_end_next_csid_l3vpn_test.sh