From: Tom Parkin <tparkin@katalix.com>
To: Guillaume Nault <gnault@redhat.com>
Cc: Ridge Kennedy <ridge.kennedy@alliedtelesis.co.nz>,
netdev@vger.kernel.org
Subject: Re: [PATCH net] l2tp: Allow duplicate session creation with UDP
Date: Mon, 20 Jan 2020 11:47:40 +0000 [thread overview]
Message-ID: <20200120114740.GA12373@jackdaw> (raw)
In-Reply-To: <20200118175224.GB12036@linux.home>
[-- Attachment #1: Type: text/plain, Size: 938 bytes --]
On Sat, Jan 18, 2020 at 18:52:24 +0100, Guillaume Nault wrote:
> On Fri, Jan 17, 2020 at 07:29:12PM +0000, Tom Parkin wrote:
> > On Fri, Jan 17, 2020 at 17:36:27 +0100, Guillaume Nault wrote:
> > > To summarise, my understanding is that global session IDs would follow
> > > the spirit of RFC 3931 and would allow establishing multiple L2TPv3
> > > connections (tunnels) over the same 5-tuple (or 3-tuple for IP encap).
> > > Per socket session IDs don't, but would allow fixing Ridge's case.
> >
> > I'm not 100% certain what "per socket session IDs" means here. Could
> > you clarify?
> >
> By "per socket session IDs", I mean that the session IDs have to be
> interpreted in the context of their parent tunnel socket (the current
> l2tp_udp_recv_core() approach). That's opposed to "global session IDs"
> which have netns-wide significance (the current l2tp_ip_recv()
> approach).
>
OK, thanks for confirming.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-01-20 11:47 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-15 22:34 [PATCH net] l2tp: Allow duplicate session creation with UDP Ridge Kennedy
2020-01-16 12:31 ` Tom Parkin
2020-01-16 19:28 ` Guillaume Nault
2020-01-16 21:05 ` Tom Parkin
2020-01-17 13:43 ` Guillaume Nault
2020-01-17 18:59 ` Tom Parkin
2020-01-18 17:18 ` Guillaume Nault
2020-01-16 12:38 ` Guillaume Nault
2020-01-16 13:12 ` Tom Parkin
2020-01-16 19:05 ` Guillaume Nault
2020-01-16 21:23 ` Tom Parkin
2020-01-16 21:50 ` Ridge Kennedy
2020-01-17 13:18 ` Tom Parkin
2020-01-17 14:25 ` Guillaume Nault
2020-01-17 19:19 ` Tom Parkin
2020-01-18 19:13 ` Guillaume Nault
2020-01-20 15:09 ` Tom Parkin
2020-01-21 16:35 ` Guillaume Nault
2020-01-22 11:55 ` James Chapman
2020-01-25 11:57 ` Guillaume Nault
2020-01-27 9:25 ` James Chapman
2020-01-29 11:44 ` Guillaume Nault
2020-01-30 10:28 ` James Chapman
2020-01-30 22:34 ` Guillaume Nault
2020-01-31 8:12 ` James Chapman
2020-01-31 12:49 ` Guillaume Nault
2020-01-31 9:55 ` Tom Parkin
2020-01-31 12:50 ` Guillaume Nault
2020-01-17 16:36 ` Guillaume Nault
2020-01-17 19:29 ` Tom Parkin
2020-01-18 17:52 ` Guillaume Nault
2020-01-20 11:47 ` Tom Parkin [this message]
2020-01-16 21:26 ` Ridge Kennedy
2020-01-31 12:58 ` Guillaume Nault
2020-02-03 23:29 ` Ridge Kennedy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200120114740.GA12373@jackdaw \
--to=tparkin@katalix.com \
--cc=gnault@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=ridge.kennedy@alliedtelesis.co.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.