Re: [ovs-discuss] Proposal for SRv6 Encap/Decap actions
On 8/1/22 07:57, Nobuhiro MIKI wrote: > On Fri, Jul 29, 2022 at 02:16:36PM +0200, Ilya Maximets wrote: >> Unfortunately, I'm not an expert in the kernel tunneling code either. >> We will likely need a drivers/net/seg6.c or something, with implementation >> of struct rtnl_link_ops. > > It's a helpful tip. Thanks. I'll look at the implementation of > struct rtnl_link_ops. OK. Thanks! > >> This should go to upstream kernel. And, actually, the kernel datapath >> implementation was recently removed from the OVS source tree. > > I see. It will take several weeks to research and implement. As far as > I can see, kernel datapath implementation does not block the review > process of userspace datapath. Yes, sure. Will try to find some time for that. Best regards, Ilya Maximets. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Proposal for SRv6 Encap/Decap actions
On Fri, Jul 29, 2022 at 02:16:36PM +0200, Ilya Maximets wrote: > Unfortunately, I'm not an expert in the kernel tunneling code either. > We will likely need a drivers/net/seg6.c or something, with implementation > of struct rtnl_link_ops. It's a helpful tip. Thanks. I'll look at the implementation of struct rtnl_link_ops. > This should go to upstream kernel. And, actually, the kernel datapath > implementation was recently removed from the OVS source tree. I see. It will take several weeks to research and implement. As far as I can see, kernel datapath implementation does not block the review process of userspace datapath. Best Regards, Nobuhiro Miki ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Proposal for SRv6 Encap/Decap actions
On 7/29/22 07:44, Nobuhiro MIKI wrote: > On Thu, Jul 28, 2022 at 03:28:28PM +0200, Ilya Maximets wrote: >> Hi. Thanks! Sorry, we're in a "release" mode these days, so not much >> time spent on reviews for new features. > > Hi Ilya, Thank you for your reply despite your busy schedule. > >> I glanced over the patch and it adds support only for the userspace >> datapath, IIUC. I also looked at the kernel code and didn't find >> a way to create a kernel port for this type of a tunnel. Do you know >> if that is something that can be addressed from the kernel side? > > As you understand, this patch only supports userspace datapath. > I have not worked on the kernel side at all and am not sure which > code to fix. Unfortunately, I'm not an expert in the kernel tunneling code either. We will likely need a drivers/net/seg6.c or something, with implementation of struct rtnl_link_ops. > Is it possible to address this with code included in OVS source > tree, such as datapath/linux/compat/vxlan.c? Or Is it needed to > implement some kind of API in Linux upstream? This should go to upstream kernel. And, actually, the kernel datapath implementation was recently removed from the OVS source tree. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Proposal for SRv6 Encap/Decap actions
On Thu, Jul 28, 2022 at 03:28:28PM +0200, Ilya Maximets wrote: > Hi. Thanks! Sorry, we're in a "release" mode these days, so not much > time spent on reviews for new features. Hi Ilya, Thank you for your reply despite your busy schedule. > I glanced over the patch and it adds support only for the userspace > datapath, IIUC. I also looked at the kernel code and didn't find > a way to create a kernel port for this type of a tunnel. Do you know > if that is something that can be addressed from the kernel side? As you understand, this patch only supports userspace datapath. I have not worked on the kernel side at all and am not sure which code to fix. Is it possible to address this with code included in OVS source tree, such as datapath/linux/compat/vxlan.c? Or Is it needed to implement some kind of API in Linux upstream? Best Regards, Nobuhiro Miki ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Proposal for SRv6 Encap/Decap actions
On 7/28/22 08:16, Nobuhiro MIKI wrote: > On Thu, Apr 28, 2022 at 04:53:44PM +0900, Nobuhiro MIKI wrote: >> On Mon, Apr 25, 2022 at 05:59:59PM +0200, Ilya Maximets wrote: >>> Hi. Sorry for the late reply. >>> >>> The feature might be interesting indeed, but the port-based implementation >>> is preferred. Creating and maintaining new actions is much more difficult >>> and all other lightweight-tunnel-based stuff is implemented as tunnel ports, >>> not separate actions. So, it's better to re-use the common infrastructure. >> >> Hi Ilya, >> >> Thank you for your helpful advice. >> I'll plan and re-implement this feature using a port-based approach. Then >> I'll >> test whether it achieves our requirements, e.g. how flexible it is to control >> SIDs. It may take a few weeks, but let me discuss it again in this ML. > > Hi Ilya, > > I've reimplemented it with a port-based approach, please see the patch below: > > https://mail.openvswitch.org/pipermail/ovs-dev/2022-July/395536.html > > The design is similar to other tunnel ports like VXLAN and GRE. > Could you please review it when you have time? Hi. Thanks! Sorry, we're in a "release" mode these days, so not much time spent on reviews for new features. I glanced over the patch and it adds support only for the userspace datapath, IIUC. I also looked at the kernel code and didn't find a way to create a kernel port for this type of a tunnel. Do you know if that is something that can be addressed from the kernel side? Best regards, Ilya Maximets. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Proposal for SRv6 Encap/Decap actions
On Thu, Apr 28, 2022 at 04:53:44PM +0900, Nobuhiro MIKI wrote: > On Mon, Apr 25, 2022 at 05:59:59PM +0200, Ilya Maximets wrote: > > Hi. Sorry for the late reply. > > > > The feature might be interesting indeed, but the port-based implementation > > is preferred. Creating and maintaining new actions is much more difficult > > and all other lightweight-tunnel-based stuff is implemented as tunnel ports, > > not separate actions. So, it's better to re-use the common infrastructure. > > Hi Ilya, > > Thank you for your helpful advice. > I'll plan and re-implement this feature using a port-based approach. Then I'll > test whether it achieves our requirements, e.g. how flexible it is to control > SIDs. It may take a few weeks, but let me discuss it again in this ML. Hi Ilya, I've reimplemented it with a port-based approach, please see the patch below: https://mail.openvswitch.org/pipermail/ovs-dev/2022-July/395536.html The design is similar to other tunnel ports like VXLAN and GRE. Could you please review it when you have time? Best Regards, Nobuhiro Miki ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Proposal for SRv6 Encap/Decap actions
On Mon, Apr 25, 2022 at 05:59:59PM +0200, Ilya Maximets wrote: > Hi. Sorry for the late reply. > > The feature might be interesting indeed, but the port-based implementation > is preferred. Creating and maintaining new actions is much more difficult > and all other lightweight-tunnel-based stuff is implemented as tunnel ports, > not separate actions. So, it's better to re-use the common infrastructure. Hi Ilya, Thank you for your helpful advice. I'll plan and re-implement this feature using a port-based approach. Then I'll test whether it achieves our requirements, e.g. how flexible it is to control SIDs. It may take a few weeks, but let me discuss it again in this ML. Best Regards, Nobuhiro Miki ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Proposal for SRv6 Encap/Decap actions
> Hi all,
>
> I am implementing SRv6 Encap/Decap actions and already have a working
> source tree, although messy. It's a huge change, so I was wondering
> if anyone could review the design before I send it off as patch series.
>
> Examples of suggested actions are as follows:
>
> actions=push_srv6(mode=encap,segs=(fc00:3::11,fc00:3::12)),output:p2
> actions=pop_srv6,output:p2
>
> Each corresponds to the following commands in iproute2 [1]:
>
> ip -6 route add ... encap seg6 mode encap segs fc00:3::11,fc00:3::12 dev p2
> ip -6 route add ... encap seg6local action End.DX4 dev p2
>
> push_srv6 accepts IPv4 or IPv6 packets. When mode=encap, it prepends IPv6
> header and SRH (Segment Routing Header) as Outer Header for encapsulation;
> when mode=inline, it inserts SRH only. Equivalent to T.encap and T.inline,
> respectively. pop_srv6 performs the reverse operation of push_srv6.
>
> Changes for push_srv6 are as follows: pop_srv6 is similar.
>
> Files Changes
> -
> -
> datapath/linux/compat/include/linux/openvswitch.h add
> OVS_ACTION_ATTR_PUSH_SRV6 to enum ovs_action_attr
> include/openvswitch/ofp-actions.h add PUSH_SRV6 to OFPACTS
> include/openvswitch/ofp-actions.h add struct ofpact_push_srv6
> lib/ofp-actions.c add
> {decode_OFPAT_RAW11,encode,parse,format,check}_PUSH_SRV6
> lib/packets.c add dp_packet_resize_l3
> lib/packets.c add push_srv6
>
> As an alternative idea, a port-based implementation like
> “ovs-vsctl add-port ... set interface ... type=srv6 options:sids=...”
> was considered. But this patch series doesn’t use port-based
> implementation because it is desirable to have flexible control over
> SIDs (Segment IDs) by flow rules.
Hi. Sorry for the late reply.
The feature might be interesting indeed, but the port-based implementation
is preferred. Creating and maintaining new actions is much more difficult
and all other lightweight-tunnel-based stuff is implemented as tunnel ports,
not separate actions. So, it's better to re-use the common infrastructure.
For the flexible control over SIDs by flow rules, you may achieve that with
options:srv6_sids=flow configuration. For example, see how the remote_ip=flow
or options:erspan_idx=flow are implemented. See the
http://www.openvswitch.org/support/dist-docs/ovs-fields.7.txt
``Flow-based’’ tunnels section, for the usage exmaple.
Best regards, Ilya Maximets.
>
> As you may know, SRv6 is already implemented in some data planes, including
> Linux, VPP, P4, and XDP [2]. Since many users already have important assets
> using OVS ecosystem, I think it is significant to be able to keep them and
> support SRv6.
>
> I am new to OVS, so any comments would be greatly appreciated.
>
> [1] https://man7.org/linux/man-pages/man8/ip-route.8.html
> [2] https://www.segment-routing.net/open-software
>
> Best Regards,
> Nobuhiro Miki
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Proposal for SRv6 Encap/Decap actions
Hi all,
I am implementing SRv6 Encap/Decap actions and already have a working
source tree, although messy. It's a huge change, so I was wondering
if anyone could review the design before I send it off as patch series.
Examples of suggested actions are as follows:
actions=push_srv6(mode=encap,segs=(fc00:3::11,fc00:3::12)),output:p2
actions=pop_srv6,output:p2
Each corresponds to the following commands in iproute2 [1]:
ip -6 route add ... encap seg6 mode encap segs fc00:3::11,fc00:3::12 dev p2
ip -6 route add ... encap seg6local action End.DX4 dev p2
push_srv6 accepts IPv4 or IPv6 packets. When mode=encap, it prepends IPv6
header and SRH (Segment Routing Header) as Outer Header for encapsulation;
when mode=inline, it inserts SRH only. Equivalent to T.encap and T.inline,
respectively. pop_srv6 performs the reverse operation of push_srv6.
Changes for push_srv6 are as follows: pop_srv6 is similar.
Files Changes
-
-
datapath/linux/compat/include/linux/openvswitch.h add
OVS_ACTION_ATTR_PUSH_SRV6 to enum ovs_action_attr
include/openvswitch/ofp-actions.h add PUSH_SRV6 to OFPACTS
include/openvswitch/ofp-actions.h add struct ofpact_push_srv6
lib/ofp-actions.c add
{decode_OFPAT_RAW11,encode,parse,format,check}_PUSH_SRV6
lib/packets.c add dp_packet_resize_l3
lib/packets.c add push_srv6
As an alternative idea, a port-based implementation like
“ovs-vsctl add-port ... set interface ... type=srv6 options:sids=...”
was considered. But this patch series doesn’t use port-based
implementation because it is desirable to have flexible control over
SIDs (Segment IDs) by flow rules.
As you may know, SRv6 is already implemented in some data planes, including
Linux, VPP, P4, and XDP [2]. Since many users already have important assets
using OVS ecosystem, I think it is significant to be able to keep them and
support SRv6.
I am new to OVS, so any comments would be greatly appreciated.
[1] https://man7.org/linux/man-pages/man8/ip-route.8.html
[2] https://www.segment-routing.net/open-software
Best Regards,
Nobuhiro Miki
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
