Re: [net-next v2 3/3] selftests: seg6: add selftest for NEXT-C-SID flavor in SRv6 End behavior

[David Ahern <dsahern@kernel.org>]

On 9/12/22 11:16 AM, Andrea Mayer wrote:
> This selftest is designed for testing the support of NEXT-C-SID flavor
> for SRv6 End behavior. It instantiates a virtual network composed of
> several nodes: hosts and SRv6 routers. Each node is realized using a
> network namespace that is properly interconnected to others through veth
> pairs.
> The test considers SRv6 routers implementing IPv4/IPv6 L3 VPNs leveraged
> by hosts for communicating with each other. Such routers i) apply
> different SRv6 Policies to the traffic received from connected hosts,
> considering the IPv4 or IPv6 protocols; ii) use the NEXT-C-SID
> compression mechanism for encoding several SRv6 segments within a single
> 128-bit SID address, referred to as a Compressed SID (C-SID) container.
> 
> The NEXT-C-SID is provided as a "flavor" of the SRv6 End behavior,
> enabling it to properly process the C-SID containers. The correct
> execution of the enabled NEXT-C-SID SRv6 End behavior is verified
> through reachability tests carried out between hosts belonging to the
> same VPN.
> 
> Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
> ---
>  tools/testing/selftests/net/Makefile          |    1 +
>  .../net/srv6_end_next_csid_l3vpn_test.sh      | 1145 +++++++++++++++++
>  2 files changed, 1146 insertions(+)
>  create mode 100755 tools/testing/selftests/net/srv6_end_next_csid_l3vpn_test.sh
> 
> diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
> index f5ac1433c301..d87e8739bb30 100644
> --- a/tools/testing/selftests/net/Makefile
> +++ b/tools/testing/selftests/net/Makefile
> @@ -37,6 +37,7 @@ TEST_PROGS += srv6_end_dt4_l3vpn_test.sh
>  TEST_PROGS += srv6_end_dt6_l3vpn_test.sh
>  TEST_PROGS += srv6_hencap_red_l3vpn_test.sh
>  TEST_PROGS += srv6_hl2encap_red_l2vpn_test.sh
> +TEST_PROGS += srv6_end_next_csid_l3vpn_test.sh
>  TEST_PROGS += vrf_strict_mode_test.sh
>  TEST_PROGS += arp_ndisc_evict_nocarrier.sh
>  TEST_PROGS += ndisc_unsolicited_na_test.sh
> diff --git a/tools/testing/selftests/net/srv6_end_next_csid_l3vpn_test.sh b/tools/testing/selftests/net/srv6_end_next_csid_l3vpn_test.sh
> new file mode 100755
> index 000000000000..87e414cc417c
> --- /dev/null
> +++ b/tools/testing/selftests/net/srv6_end_next_csid_l3vpn_test.sh
> @@ -0,0 +1,1145 @@
> +#!/bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# author: Andrea Mayer <andrea.mayer@uniroma2.it>
> +#
> +# This script is designed for testing the support of NEXT-C-SID flavor for SRv6
> +# End behavior.
> +# A basic knowledge of SRv6 architecture [1] and of the compressed SID approach
> +# [2] is assumed for the reader.
> +#
> +# The network topology used in the selftest is depicted hereafter, composed by
> +# two hosts and four routers. Hosts hs-1 and hs-2 are connected through an
> +# IPv4/IPv6 L3 VPN service, offered by routers rt-1, rt-2, rt-3 and rt-4 using
> +# the NEXT-C-SID flavor. The key components for such VPNs are:
> +#
> +#    i) The SRv6 H.Encaps/H.Encaps.Red behaviors [1] apply SRv6 Policies on
> +#       traffic received by connected hosts, initiating the VPN tunnel;
> +#
> +#   ii) The SRv6 End behavior [1] advances the active SID in the SID List
> +#       carried by the SRH;
> +#
> +#  iii) The NEXT-C-SID mechanism [2] offers the possibility of encoding several
> +#       SRv6 segments within a single 128-bit SID address, referred to as a
> +#       Compressed SID (C-SID) container. In this way, the length of the SID
> +#       List can be drastically reduced.
> +#       The NEXT-C-SID is provided as a "flavor" of the SRv6 End behavior
> +#       which advances the current C-SID (i.e. the Locator-Node Function defined
> +#       in [2]) with the next one carried in the Argument, if available.
> +#       When no more C-SIDs are available in the Argument, the SRv6 End behavior
> +#       will apply the End function selecting the next SID in the SID List.
> +#
> +#   iv) The SRv6 End.DT46 behavior [1] is used for removing the SRv6 Policy and,
> +#       thus, it terminates the VPN tunnel. Such a behavior is capable of
> +#       handling, at the same time, both tunneled IPv4 and IPv6 traffic.
> +#
> +# [1] https://datatracker.ietf.org/doc/html/rfc8986
> +# [2] https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression
> +#
> +#
> +#               cafe::1                      cafe::2
> +#              10.0.0.1                     10.0.0.2
> +#             +--------+                   +--------+
> +#             |        |                   |        |
> +#             |  hs-1  |                   |  hs-2  |
> +#             |        |                   |        |
> +#             +---+----+                   +----+---+
> +#    cafe::/64    |                             |      cafe::/64
> +#  10.0.0.0/24    |                             |    10.0.0.0/24
> +#             +---+----+                   +----+---+
> +#             |        |  fcf0:0:1:2::/64  |        |
> +#             |  rt-1  +-------------------+  rt-2  |
> +#             |        |                   |        |
> +#             +---+----+                   +----+---+
> +#                 |      .               .      |
> +#                 |  fcf0:0:1:3::/64   .        |
> +#                 |          .       .          |
> +#                 |            .   .            |
> +# fcf0:0:1:4::/64 |              .              | fcf0:0:2:3::/64
> +#                 |            .   .            |
> +#                 |          .       .          |
> +#                 |  fcf0:0:2:4::/64   .        |
> +#                 |      .               .      |
> +#             +---+----+                   +----+---+
> +#             |        |                   |        |
> +#             |  rt-4  +-------------------+  rt-3  |
> +#             |        |  fcf0:0:3:4::/64  |        |
> +#             +---+----+                   +----+---+
> +#
> +# Every fcf0:0:x:y::/64 network interconnects the SRv6 routers rt-x with rt-y in
> +# the selftest network.
> +#
> +# Local SID/C-SID table
> +# =====================
> +#
> +# Each SRv6 router is configured with a Local SID/C-SID table in which
> +# SIDs/C-SIDs are stored. Considering an SRv6 router rt-x, SIDs/C-SIDs are
> +# configured in the Local SID/C-SIDs table as follows:
> +#
> +#   Local SID/C-SID table for SRv6 router rt-x
> +#   +-----------------------------------------------------------+
> +#   |fcff:x::d46 is associated with the non-compressed SRv6     |
> +#   |   End.DT46 behavior                                       |
> +#   +-----------------------------------------------------------+
> +#   |fcbb:0:0x00::/48 is associated with the NEXT-C-SID flavor  |
> +#   |   of SRv6 End behavior                                    |
> +#   +-----------------------------------------------------------+
> +#   |fcbb:0:0x00:d46::/64 is associated with the SRv6 End.DT46  |
> +#   |   behavior when NEXT-C-SID compression is turned on       |
> +#   +-----------------------------------------------------------+
> +#
> +# The fcff::/16 prefix is reserved for implementing SRv6 services with regular
> +# (non compressed) SIDs. Reachability of SIDs is ensured by proper configuration
> +# of the IPv6 routing tables in the routers.
> +# Similarly, the fcbb:0::/32 prefix is reserved for implementing SRv6 VPN
> +# services leveraging the NEXT-C-SID compression mechanism. Indeed, the
> +# fcbb:0::/32 is used for encoding the Locator-Block while the Locator-Node
> +# Function is encoded with 16 bits.
> +#
> +# Incoming traffic classification and application of SRv6 Policies
> +# ================================================================
> +#
> +# An SRv6 ingress router applies different SRv6 Policies to the traffic received
> +# from a connected host, considering the IPv4 or IPv6 destination address.
> +# SRv6 policy enforcement consists of encapsulating the received traffic into a
> +# new IPv6 packet with a given SID List contained in the SRH.
> +# When the SID List contains only one SID, the SRH could be omitted completely
> +# and that SID is stored directly in the IPv6 Destination Address (DA) (this is
> +# called "reduced" encapsulation).
> +#
> +# Test cases for NEXT-C-SID
> +# =========================
> +#
> +# We consider two test cases for NEXT-C-SID: i) single SID and ii) double SID.
> +#
> +# In the single SID test case we have a number of segments that are all
> +# contained in a single Compressed SID (C-SID) container. Therefore the
> +# resulting SID List has only one SID. Using the reduced encapsulation format
> +# this will result in a packet with no SRH.
> +#
> +# In the double SID test case we have one segment carried in a Compressed SID
> +# (C-SID) container, followed by a regular (non compressed) SID. The resulting
> +# SID List has two segments and it is possible to test the advance to the next
> +# SID when all the C-SIDs in a C-SID container have been processed. Using the
> +# reduced encapsulation format this will result in a packet with an SRH
> +# containing 1 segment.
> +#
> +# For the single SID test case, we use the IPv4 addresses of hs-1 and hs-2, for
> +# the double SID test case, we use their IPv6 addresses. This is only done to
> +# simplify the test setup and avoid adding other hosts or multiple addresses on
> +# the same interface of a host.
> +#
> +# Traffic from hs-1 to hs-2
> +# -------------------------
> +#
> +# Packets generated from hs-1 and directed towards hs-2 are handled by rt-1
> +# which applies the SRv6 Policies as follows:
> +#
> +#   i) IPv6 DA=cafe::2, H.Encaps.Red with SID List=fcbb:0:0400:0300:0200:d46::
> +#  ii) IPv4 DA=10.0.0.2, H.Encaps.Red with SID List=fcbb:0:0300::,fcff:2::d46
> +#
> +# ### i) single SID
> +#
> +# The router rt-1 is configured to enforce the given Policy through the SRv6
> +# H.Encaps.Red behavior which avoids the presence of the SRH at all, since it
> +# pushes the single SID directly in the IPv6 DA. Such a SID encodes a whole
> +# C-SID container carrying several C-SIDs (e.g. 0400, 0300, etc).
> +#
> +# As the packet reaches the router rt-4, the enabled NEXT-C-SID SRv6 End
> +# behavior (associated with fcbb:0:0400::/48) is triggered. This behavior
> +# analyzes the IPv6 DA and checks whether the Argument of the C-SID container
> +# is zero or not. In this case, the Argument is *NOT* zero and the IPv6 DA is
> +# updated as follows:
> +#
> +# +---------------------------------------------------------------+
> +# | Before applying the rt-4 enabled NEXT-C-SID SRv6 End behavior |
> +# +---------------------------------------------------------------+
> +# |                            +---------- Argument               |
> +# |                     vvvvvvvvvvvvvvvv                          |
> +# | IPv6 DA fcbb:0:0400:0300:0200:d46::                           |
> +# |                ^^^^    <-- shifting                           |
> +# |                  |                                            |
> +# |          Locator-Node Function                                |
> +# +---------------------------------------------------------------+
> +# | After applying the rt-4 enabled NEXT-C-SID SRv6 End behavior  |
> +# +---------------------------------------------------------------+
> +# |                          +---------- Argument                 |
> +# |                    vvvvvvvvvvvv                               |
> +# | IPv6 DA fcbb:0:0300:0200:d46::                                |
> +# |                ^^^^                                           |
> +# |                  |                                            |
> +# |          Locator-Node Function                                |
> +# +---------------------------------------------------------------+
> +#
> +# After having applied the enabled NEXT-C-SID SRv6 End behavior, the packet is
> +# sent to the next node, i.e. rt-3.
> +#
> +# The enabled NEXT-C-SID SRv6 End behavior on rt-3 is executed as the packet is
> +# received. This behavior processes the packet and updates the IPv6 DA with
> +# fcbb:0:0200:d46::, since the Argument is *NOT* zero. Then, the packet is sent
> +# to the router rt-2.
> +#
> +# The router rt-2 is configured for decapsulating the inner IPv6 packet and,
> +# for this reason, it applies the SRv6 End.DT46 behavior on the received
> +# packet. It is worth noting that the SRv6 End.DT46 behavior does not require
> +# the presence of the SRH: it is fully capable to operate properly on
> +# IPv4/IPv6-in-IPv6 encapsulations.
> +# At the end of the decap operation, the packet is sent to the
> +# host hs-2.
> +#
> +# ### ii) double SID
> +#
> +# The router rt-1 is configured to enforce the given Policy through the SRv6
> +# H.Encaps.Red. As a result, the first SID fcbb:0:0300:: is stored into the
> +# IPv6 DA, while the SRH pushed into the packet is made of only one SID, i.e.
> +# fcff:2::d46. Hence, the packet sent by hs-1 to hs-2 is encapsulated in an
> +# outer IPv6 header plus the SRH.
> +#
> +# As the packet reaches the node rt-3, the router applies the enabled NEXT-C-SID
> +# SRv6 End behavior.
> +#
> +# +---------------------------------------------------------------+
> +# | Before applying the rt-3 enabled NEXT-C-SID SRv6 End behavior |
> +# +---------------------------------------------------------------+
> +# |                            +---------- Argument               |
> +# |                      vvvv (Argument is all filled with zeros) |
> +# | IPv6 DA fcbb:0:0300::                                         |
> +# |                ^^^^                                           |
> +# |                  |                                            |
> +# |          Locator-Node Function                                |
> +# +---------------------------------------------------------------+
> +# | After applying the rt-3 enabled NEXT-C-SID SRv6 End behavior  |
> +# +---------------------------------------------------------------+
> +# |                                                               |
> +# | IPv6 DA fcff:2::d46                                           |
> +# |         ^^^^^^^^^^^                                           |
> +# |              |                                                |
> +# |        SID copied from the SID List contained in the SRH      |
> +# +---------------------------------------------------------------+
> +#
> +# Since the Argument of the C-SID container is zero, the behavior can not
> +# update the Locator-Node function with the next C-SID carried in the Argument
> +# itself. Thus, the enabled NEXT-C-SID SRv6 End behavior operates as the
> +# traditional End behavior: it updates the IPv6 DA by copying the next
> +# available SID in the SID List carried by the SRH. After that, the packet is
> +# sent to the node rt-2.
> +#
> +# Once the packet is received by rt-2, the router decapsulates the inner IPv6
> +# packet using the SRv6 End.DT46 behavior (associated with the SID fcff:2::d46)
> +# and sends it to the host hs-2.
> +#
> +# Traffic from hs-2 to hs-1
> +# -------------------------
> +#
> +# Packets generated from hs-2 and directed towards hs-1 are handled by rt-2
> +# which applies the SRv6 Policies as follows:
> +#
> +#   i) IPv6 DA=cafe::1, SID List=fcbb:0:0300:0400:0100:d46::
> +#  ii) IPv4 DA=10.0.0.1, SID List=fcbb:0:0300::,fcff:1::d46
> +#
> +# For simplicity, such SRv6 Policies were chosen so that, in both use cases (i)
> +# and (ii), the network paths crossed by traffic from hs-2 to hs-1 are the same
> +# as those taken by traffic from hs-1 to hs-2.
> +# In this way, traffic from hs-2 to hs-1 is processed similarly to traffic from
> +# hs-1 to hs-2. So, the traffic processing scheme turns out to be the same as
> +# that adopted in the use cases already examined (of course, it is necessary to
> +# consider the different SIDs/C-SIDs).
> +

Thanks for the verbose description of the tests.

Acked-by: David Ahern <dsahern@kernel.org>