mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Ahern <dsahern@kernel.org>
To: Andrea Mayer <andrea.mayer@uniroma2.it>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Shuah Khan <shuah@kernel.org>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Cc: Stefano Salsano <stefano.salsano@uniroma2.it>,
	Paolo Lungaroni <paolo.lungaroni@uniroma2.it>,
	Ahmed Abdelsalam <ahabdels.dev@gmail.com>
Subject: Re: [net-next 2/3] seg6: add PSP flavor support for SRv6 End behavior
Date: Wed, 15 Feb 2023 23:07:48 -0700	[thread overview]
Message-ID: <2975663a-4cf9-b7cd-7509-9f48f815a56e@kernel.org> (raw)
In-Reply-To: <20230215134659.7613-3-andrea.mayer@uniroma2.it>

On 2/15/23 6:46 AM, Andrea Mayer wrote:
> The "flavors" framework defined in RFC8986 [1] represents additional
> operations that can modify or extend a subset of existing behaviors such as
> SRv6 End, End.X and End.T. We report these flavors hereafter:
>  - Penultimate Segment Pop (PSP);
>  - Ultimate Segment Pop (USP);
>  - Ultimate Segment Decapsulation (USD).
> 
> Depending on how the Segment Routing Header (SRH) has to be handled, an
> SRv6 End* behavior can support these flavors either individually or in
> combinations.
> In this patch, we only consider the PSP flavor for the SRv6 End behavior.
> 
> A PSP enabled SRv6 End behavior is used by the Source/Ingress SR node
> (i.e., the one applying the SRv6 Policy) when it needs to instruct the
> penultimate SR Endpoint node listed in the SID List (carried by the SRH) to
> remove the SRH from the IPv6 header.
> 
> Specifically, a PSP enabled SRv6 End behavior processes the SRH by:
>    i) decreasing the Segment Left (SL) from 1 to 0;
>   ii) copying the Last Segment IDentifier (SID) into the IPv6 Destination
>       Address (DA);
>  iii) removing (i.e., popping) the outer SRH from the extension headers
>       following the IPv6 header.
> 
> It is important to note that PSP operation (steps i, ii, iii) takes place
> only at a penultimate SR Segment Endpoint node (i.e., when the SL=1) and
> does not happen at non-penultimate Endpoint nodes. Indeed, when a SID of
> PSP flavor is processed at a non-penultimate SR Segment Endpoint node, the
> PSP operation is not performed because it would not be possible to decrease
> the SL from 1 to 0.
> 
>                                                  SL=2 SL=1 SL=0
>                                                    |    |    |
> For example, given the SRv6 policy (SID List := <  X,   Y,   Z  >):
>  - a PSP enabled SRv6 End behavior bound to SID "Y" will apply the PSP
>    operation as Segment Left (SL) is 1, corresponding to the Penultimate
>    Segment of the SID List;
>  - a PSP enabled SRv6 End behavior bound to SID "X" will *NOT* apply the
>    PSP operation as the Segment Left is 2. This behavior instance will
>    apply the "standard" End packet processing, ignoring the configured PSP
>    flavor at all.
> 
> [1] - RFC8986: https://datatracker.ietf.org/doc/html/rfc8986
> 
> Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
> ---
>  net/ipv6/seg6_local.c | 336 +++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 333 insertions(+), 3 deletions(-)
> 

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



  reply	other threads:[~2023-02-16  6:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-15 13:46 [net-next 0/3] " Andrea Mayer
2023-02-15 13:46 ` [net-next 1/3] seg6: factor out End lookup nexthop processing to a dedicated function Andrea Mayer
2023-02-16  6:06   ` David Ahern
2023-02-15 13:46 ` [net-next 2/3] seg6: add PSP flavor support for SRv6 End behavior Andrea Mayer
2023-02-16  6:07   ` David Ahern [this message]
2023-02-15 13:46 ` [net-next 3/3] selftests: seg6: add selftest for PSP flavor in " Andrea Mayer
2023-02-16  6:10   ` David Ahern
2023-02-16 14:40 ` [net-next 0/3] seg6: add PSP flavor support for " patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2975663a-4cf9-b7cd-7509-9f48f815a56e@kernel.org \
    --to=dsahern@kernel.org \
    --cc=ahabdels.dev@gmail.com \
    --cc=andrea.mayer@uniroma2.it \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=paolo.lungaroni@uniroma2.it \
    --cc=shuah@kernel.org \
    --cc=stefano.salsano@uniroma2.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®