Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 19 Apr 2023 11:49:23 +0100
From:   Tom Parkin <tparkin@katalix.com>
To:     Samuel Thibault <samuel.thibault@ens-lyon.org>,
        Guillaume Nault <gnault@redhat.com>,
        James Chapman <jchapman@katalix.com>, edumazet@google.com,
        davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
        corbet@lwn.net, netdev@vger.kernel.org, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PPPoL2TP: Add more code snippets
Message-ID: <20230419104923.GA13324@katalix.com>
References: <ZD5V+z+cBaXvPbQa@debian>
 <20230418085323.h6xij7w6d2o4kxxi@begin>
 <ZD5dqwPblo4FOex1@debian>
 <20230418091148.hh3b52zceacduex6@begin>
 <ZD5uU8Wrz4cTSwqP@debian>
 <20230418103140.cps6csryl2xhrazz@begin>
 <ZD5+MouUk8YFVOX3@debian>
 <20230418115409.aqsqi6pa4s4nhwgs@begin>
 <ZD6dON0gl3DE8mYr@debian>
 <20230418141820.gxueo5pz2vvre442@begin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4"
Content-Disposition: inline
In-Reply-To: <20230418141820.gxueo5pz2vvre442@begin>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk


--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On  Tue, Apr 18, 2023 at 16:18:20 +0200, Samuel Thibault wrote:
> Guillaume Nault, le mar. 18 avril 2023 15:38:00 +0200, a ecrit:
> > On Tue, Apr 18, 2023 at 01:54:09PM +0200, Samuel Thibault wrote:
> > > Guillaume Nault, le mar. 18 avril 2023 13:25:38 +0200, a ecrit:
> > > > As I said in my previous reply, a simple L2TP example that goes unt=
il PPP
> > > > channel and unit creation is fine. But any more advanced use of the=
 PPP
> > > > API should be documented in the PPP documentation.
> > >=20
> > > When it's really advanced, yes. But here it's just about tunnel
> > > bridging, which is a very common L2TP thing to do.
> >=20
> > I can't undestand why you absolutely want this covered in l2tp.rst.
>=20
> Because that's where people working on L2TP software will look for it.

Sorry to have not commented earlier, and thank you Samuel for working
on improving the L2TP documentation.

I think documentation like l2tp.rst is best when it provides a high
level overview of how things fit together.

When it comes to actually implementing a userspace L2TP/PPP daemon,
I feel that at a certain point you're better off referring to existing
userspace code alongside the kernel sources themselves, as any summary is
inevitably going to leave gaps.  From that perspective I'd almost sooner
we didn't have the code snippet in l2tp.rst.

That said, I can't see the harm in improving the code snippet, given
that we have it already.  Having no mention of PPPIOCBRIDGECHAN given
that it can be used to implement tunnel switching is an oversight
really.

FWIW I agree the term "tunnel switching" is a bit misleading, and of
course the PPP ioctl supports bridging any flavour of channel, not
just PPPoL2TP.  However from the L2TP perspective people perhaps have
something along the lines of this IETF draft in mind:

https://datatracker.ietf.org/doc/html/draft-ietf-l2tpext-tunnel-switching-08

=2E..which we could perhaps link to to clarify the intent in the context
of the L2TP codebase?

> > Also, it's probably a desirable feature, but certainly not a common
> > thing on Linux. This interface was added a bit more than 2 years ago,
> > which is really recent considering the age of the code.
>=20
> Yes, and in ISPs we have been in need for it for something like
> decades. I can find RFC drafts around 2000.
>=20
> Or IPs have just baked their own kernel implementation (xl2tpd,
> accel-ppp, etc.)

Yes.  It's sad that support wasn't available sooner in the kernel, but
I'm not sure that's indicative of lack of desire for the feature
necessarily.

> > Appart from maybe go-l2tp, I don't know of any user.
>=20

I confirm that go-l2tp does use it :-)

--=20
Tom Parkin
Katalix Systems Ltd
https://katalix.com
Catalysts for your Embedded Linux software development

--YiEDa0DAkWCtVeE4
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEsUkgyDzMwrj81nq0lIwGZQq6i9AFAmQ/xyYACgkQlIwGZQq6
i9At8QgAsFZhEpP2qxWypS68H5NKarIfFYarOkKszlZYYGSxuSFsx1uNYGc/m6dM
EfB4N00yMNLIhUU7gimjytfZXVTFYyoAZ4ZIxSdngkyJiSMkwGdccSlu/nTbCFwa
NbfC5v3e2/liDGDleT1CrpxrBD6IBNzG6PzUti3BhG8wJoODy2xyRbS2bDDFkjMr
GUF9rRVxlIt/+V8iOPKBvlib7mLPyRh7lSOELQqWVKLLosuaAtb5NW8vNfpnRLxz
2rg307GafbG/zgFJcDHKaYjUT2AaoEC44eh0laOFZgbUr9lJtSejjRIQROQQ00uJ
MngGtrhkFgaUEDs/cILtSqlU6G/nBA==
=gtf3
-----END PGP SIGNATURE-----

--YiEDa0DAkWCtVeE4--