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

Eelco Chaudron echaudro at redhat.com
Wed Sep 15 06:30:43 UTC 2021


Hi Martin,

It's on my list for this Friday as I'm done with the sFlow review for now.

Cheers,

Eelco

On 15 Sep 2021, at 5:01, Varghese, Martin (Nokia - IN/Bangalore) wrote:

> 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
>>



More information about the dev mailing list