From mboxrd@z Thu Jan  1 00:00:00 1970
From: Guillaume Nault <g.nault@alphalink.fr>
Subject: Re: [PATCH net-next 2/2] l2tp: add peer_offset parameter
Date: Wed, 3 Jan 2018 15:16:35 +0100
Message-ID: <20180103141635.GD1402@alphalink.fr>
References: <cover.1513951129.git.lorenzo.bianconi@redhat.com>
 <d51dc65a40c5e335984e95a1e6db0eea00d9fd13.1513951129.git.lorenzo.bianconi@redhat.com>
 <20171228145340.GA1292@alphalink.fr>
 <20171228182347.GA8732@localhost.localdomain>
 <20171228194556.GA1256@alphalink.fr>
 <27e0a7c8-b95b-04eb-d808-bcae67e417b1@katalix.com>
 <CAJ0CqmWc_-L1mXqBEDJ=UWsbJ9b-Xeug2q4MVwM_EcmTsOZyeA@mail.gmail.com>
 <20180102180557.GB1402@alphalink.fr>
 <CAJ0CqmWhhzvi8HCKjf-xUjkszuNKgnuoD_MXmDNtUtWyEExdNQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: James Chapman <jchapman@katalix.com>,
        "David S. Miller" <davem@davemloft.net>, netdev@vger.kernel.org,
        Hangbin Liu <liuhangbin@gmail.com>
To: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from zimbra.alphalink.fr ([217.15.80.77]:60230 "EHLO
        zimbra.alphalink.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752802AbeACOQi (ORCPT
        <rfc822;netdev@vger.kernel.org>); Wed, 3 Jan 2018 09:16:38 -0500
Content-Disposition: inline
In-Reply-To: <CAJ0CqmWhhzvi8HCKjf-xUjkszuNKgnuoD_MXmDNtUtWyEExdNQ@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Tue, Jan 02, 2018 at 08:28:03PM +0100, Lorenzo Bianconi wrote:
> Perhaps I am little bit polarized on UABI issue, but I was rethinking
> about it and maybe removing offset parameter would lead to an
> interoperability issue for device running L2TPv3 since offset
> parameter is there and it is not a nope.
> Please consider this setup:
> - 2 endpoint running L2TPv3, the first running net-next and the second
> running 4.14
> - both endpoint are configured using iproute2 in this way:
> 
>   - ip l2tp add tunnel local <ip0> remote <ip1> tunnel_id <id0>
> peer_tunnel_id <id1> udp_sport <p0> udp_dport <p1>
>   - ip l2tp add tunnel local <ip1> remote <ip0> tunnel_id <id1>
> peer_tunnel_id <id0> udp_sport <p1> udp_dport <p0>
>   - ip l2tp add session name l2tp0 tunnel_id <id0> session_id <s0>
> peer_session_id <s1> offset 8
>   - ip l2tp add session name l2tp0 tunnel_id <id1> session_id <s1>
> peer_session_id <s0> offset 8
> 
> Can we assume offset is never used for L2TPv3?
>
That's what I think. You're right worrying about ABI issues. And I
wouldn't dare proposing such a removal if I had doubts about breaking a
user setup.

Considering the lack of use cases and the absence of interoperability
of this feature, I hardly can imagine it being used.
But it's not only that: the feature has been buggy for years without
anyone noticing. And this bug wasn't difficult to spot (one just needs
to look at an L2TPv3 header in a network packet dump).

It's really the combination of these three issues (buggy, no use case
and not producing valid L2TPv3 frames) that makes me propose a removal.