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, it is 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
v1 -> v2:
- Fix author tags in the commit message in patch 2/2, thanks to Paolo Abeni;
- Remove unnecessary supp_ops == 0 check in patch 1/2, thanks to Hangbin Liu;
- Fix 'is it possible' -> 'it is possible' in cover letter, thanks to
Hangbin Liu.
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
--
2.20.1
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <[email protected]>:
On Sat, 12 Aug 2023 20:09:24 +0200 you wrote:
> 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).
>
> [...]
Here is the summary with links:
- [net-next,v2,1/2] seg6: add NEXT-C-SID support for SRv6 End.X behavior
https://git.kernel.org/netdev/net-next/c/7458575a07f1
- [net-next,v2,2/2] selftests: seg6: add selftest for NEXT-C-SID flavor in SRv6 End.X behavior
https://git.kernel.org/netdev/net-next/c/1c53717c8074
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html