netdev - Re: [PATCH net-next 3/3] openvswitch: New MPLS actions for layer 2 tunnelling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOrHB_D0sjWcFR6KfXidDSk=5pWPMzStF2vU+GRQZ4KCVcm5tA@mail.gmail.com>
Date:   Tue, 10 Dec 2019 22:15:19 -0800
From:   Pravin Shelar <pshelar@....org>
To:     Martin Varghese <martinvarghesenokia@...il.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>, scott.drennan@...ia.com,
        Jiri Benc <jbenc@...hat.com>,
        "Varghese, Martin (Nokia - IN/Bangalore)" <martin.varghese@...ia.com>
Subject: Re: [PATCH net-next 3/3] openvswitch: New MPLS actions for layer 2 tunnelling

On Tue, Dec 10, 2019 at 4:02 PM Martin Varghese
<martinvarghesenokia@...il.com> wrote:
>
> On Tue, Dec 10, 2019 at 01:22:56PM -0800, Pravin Shelar wrote:
> > On Tue, Dec 10, 2019 at 12:17 AM Martin Varghese
> > <martinvarghesenokia@...il.com> wrote:
> > >
> > > From: Martin Varghese <martin.varghese@...ia.com>
> > >
> > > The existing PUSH MPLS & POP MPLS actions inserts & removes MPLS header
> > > between ethernet header and the IP header. Though this behaviour is fine
> > > for L3 VPN where an IP packet is encapsulated inside a MPLS tunnel, it
> > > does not suffice the L2 VPN (l2 tunnelling) requirements. In L2 VPN
> > > the MPLS header should encapsulate the ethernet packet.
> > >
> > > The new mpls actions PTAP_PUSH_MPLS & PTAP_POP_MPLS inserts and removes
> > > MPLS header from start of the packet respectively.
> > >
> > > PTAP_PUSH_MPLS - Inserts MPLS header at the start of the packet.
> > > @ethertype - Ethertype of MPLS header.
> > >
> > > PTAP_POP_MPLS - Removes MPLS header from the start of the packet.
> > > @ethertype - Ethertype of next header following the popped MPLS header.
> > >              Value 0 in ethertype indicates the tunnelled packet is
> > >              ethernet.
> > >
> > Did you considered using existing MPLS action to handle L2 tunneling
> > packet ? It can be done by adding another parameter to the MPLS
> > actions.
>

>
>
> Not really.
>
> Are you suggesting to extend the ovs_action_push_mpls and similarly for pop
>
> struct ovs_action_push_mpls {
>         __be32 mpls_lse;
>         __be16 mpls_ethertype; /* Either %ETH_P_MPLS_UC or %ETH_P_MPLS_MC */
> +        bool l2_tunnel;
> };
>
> Does not that break the compatibilty with the existing userspace
> OVS ?
>
Right, extending this would not look good. I am fine with new action.
But we can design this new action as superset of existing and PTAP
functionality, This way in future we can deprecate existing MPLS
action in favor of new action.
I think if you add mac_len parameter for the action it would take case
of both cases.