[ovs-dev] [PATCH v4 0/2] Encap & Decap actions for MPLS packet type

[Varghese, Martin (Nokia - IN/Bangalore)]

HI Eelco,

I have sent the v5 couple of weeks back. In case if you have not noticed.

Regards,
Martin

-----Original Message-----
From: Martin Varghese <martinvarghesenokia at gmail.com> 
Sent: Tuesday, June 15, 2021 9:32 AM
To: Eelco Chaudron <echaudro at redhat.com>
Cc: dev at openvswitch.org; pshelar at ovn.org; Varghese, Martin (Nokia - IN/Bangalore) <martin.varghese at nokia.com>
Subject: Re: [PATCH v4 0/2] Encap & Decap actions for MPLS packet type

On Mon, Jun 14, 2021 at 03:09:39PM +0200, Eelco Chaudron wrote:
> Hi Martin,
> 
> What is the status of this patchset? Are you going to send out a v5, as I noticed quite some discussion with Jan, but I lost track?
>

HI Eelco,

I am waiting for the below patches to get merged.


http://patchwork.ozlabs.org/project/openvswitch/patch/20210609133611.2013-1-martinvarghesenokia@gmail.com/

http://patchwork.ozlabs.org/project/openvswitch/patch/20210427124244.2358-1-martinvarghesenokia@gmail.com/

Regards,
Martin


> //Eelco
> 
> 
> On 30 Mar 2021, at 18:49, Martin Varghese wrote:
> 
> > On Tue, Mar 30, 2021 at 05:26:19PM +0200, Eelco Chaudron wrote:
> >>
> >>
> >> On 26 Mar 2021, at 7:20, Martin Varghese wrote:
> >>
> >>> From: Martin Varghese <martin.varghese at nokia.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 requirements. 
> >>> In L2 VPN the ethernet packets must be encapsulated inside MPLS 
> >>> tunnel
> >>>
> >>> In this change the encap & decap actions are extended to support 
> >>> MPLS packet type. The encap & decap adds and removes MPLS header 
> >>> at the start of packet as depicted below.
> >>>
> >>> Encapsulation:
> >>>
> >>> Actions - encap(mpls(ether_type=0x8847)),encap(ethernet)
> >>>
> >>> Incoming packet -> | ETH | IP | Payload |
> >>>
> >>> 1 Actions -  encap(mpls(ether_type=0x8847)) [Datapath action - 
> >>> ADD_MPLS:0x8847]
> >>>
> >>>         Outgoing packet -> | MPLS | ETH | Payload|
> >>>
> >>> 2 Actions - encap(ethernet) [ Datapath action - push_eth ]
> >>>
> >>>         Outgoing packet -> | ETH | MPLS | ETH | Payload|
> >>>
> >>> Decapsulation:
> >>>
> >>> Incoming packet -> | ETH | MPLS | ETH | IP | Payload |
> >>>
> >>> Actions - decap(),decap(packet_type(ns=0,type=0)
> >>>
> >>> 1 Actions -  decap() [Datapath action - pop_eth)
> >>>
> >>>         Outgoing packet -> | MPLS | ETH | IP | Payload|
> >>>
> >>> 2 Actions - decap(packet_type(ns=0,type=0) [Datapath action - 
> >>> POP_MPLS:0x6558]
> >>>
> >>>         Outgoing packet -> | ETH  | IP | Payload|
> >>
> >> I started off by running the self-tests with an older kernel, and 
> >> this is
> >> failing:
> >>
> >> $ make -j $(nproc) check-kernel TESTSUITEFLAGS='-k mpls'
> >> ...
> >> ## ------------------------------- ## ## openvswitch 2.15.90 test 
> >> suite. ## ## ------------------------------- ##
> >>
> >> datapath-sanity
> >>
> >>  26: datapath - mpls actions                         ok
> >>  27: datapath - multiple mpls label pop              FAILED
> >> (system-traffic.at:1026)
> >>  28: datapath - ptap mpls actions                    ok
> >>
> >> layer3-tunnels
> >>
> >> 137: layer3 - ping over MPLS Bareudp                 skipped
> >> (system-layer3-tunnels.at:157)
> >>
> >> I would assume 28 would fail or be skipped as the feature is missing.
> >> 27 should pass as your change should be backward compatible. Can you check?
> >>
> > 28 is the test for this feature. It is passing as it is backward 
> > compatible.
> > 27 is the test for the existing feature. It is failing as older 
> > kernel doesnot support this feature
> >>
> >> Also, it would be nice, if you sent out a new version to keep some 
> >> history, so we have an idea of what has changed.
> >>
> > Yes i will send out a new version with change log
> >>
> >
> > Regards
> > Martin
>