mbox series

[net-next,0/2] seg6: add NEXT-C-SID support for SRv6 End.X behavior

Message ID 20230731175117.17376-1-andrea.mayer@uniroma2.it
Headers
Series seg6: add NEXT-C-SID support for SRv6 End.X behavior |

Message

Andrea Mayer July 31, 2023, 5:51 p.m. UTC 
  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

Comments

Hangbin Liu Aug. 3, 2023, 9:26 a.m. UTC | #1 
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...