netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <dlezcano@fr.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>, Kirill Korotaev <dev@sw.ru>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Dmitry Mishin <dim@sw.ru>,
	netdev@vger.kernel.org
Subject: Re: [patch -mm] net namespace: empty framework
Date: Wed, 22 Nov 2006 23:56:55 +0100	[thread overview]
Message-ID: <4564D5B7.7030307@fr.ibm.com> (raw)
In-Reply-To: <m1ejrvtlje.fsf@ebiederm.dsl.xmission.com>

Eric W. Biederman wrote:
> The justification is performance and a little on the simplicity side.
> 
> My personal feel is still that layer 3 is something easier done
> as a new kind of table in an iptables type infrastructure.  And in
> fact I believe if done that way would capture do what 90%+ of what
> all of the iptables rules do.  So it might be a nice firewalling speed up.
> I don't think the layer 3 idea where you just do bind filter fits
> the namespace concept very well.

The question is why do we need to do isolation/virtualization at the 
layer 3 ?

1 - for security
2 - for ressource management
3 - for mobility

The last one is not implementable with a netfilter only solution. The 
solution is to have a container id by sockets in order to identify them 
and to descriminate the sockets owned by the container for 
checkpoint/restart and for quescient point. If you look closely to the 
layer 3 approach with network isolation you will see if we replace the 
container id by the network namespace pointer, the code is the *same*.
So we have a common code for the layer 4 for namespaces and layer 3 
isolation. Pushing a little more the layer 3 isolation into namespaces 
we have reach a common solution for layer 2 and layer 3 with Dmitry and 
made the two to co-exists.

The next step will be to reach a quescient point in order to 
checkpoint/restart. The quescient point will be reach using the 
namespace identifier, the traffic will be dropped for incoming and 
outgoing traffic and network timers will be frozen. Should we have again 
two approaches ? One for the layer 2 and another one for the layer 3, 
instead of using the same mechanism for namespaces ?
After that the checkpoint will use the network namespace in order to 
find the sockets to be checkpointed. Should we have 2 checkpoint/restart 
mechanisms ?

I agree, some part of the layer 3 approach does not fit the namespaces 
concept very well, but this is a conceptual vision of the namespaces. I 
can argue, the layer 2 does not fit the namespace concept too, the 
socket hashtable are not by namespaces, the routes cache are not by 
namespaces, does it mean it does not fit the namespace concept at all ? 
No, it does, but it is written to be optimized, it is a question of 
performance...

I don't want to enter to the debate, again, about layer 2/3 
isolation/virtualization, I did my best to promote layer 2 and to 
justify layer 3 on top of that. Now, I let the network guys to decide...

   -- Daniel

  reply	other threads:[~2006-11-22 22:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-21 13:34 [patch -mm] net namespace: empty framework Cedric Le Goater
2006-11-21 13:51 ` Kirill Korotaev
2006-11-21 18:01   ` Daniel Lezcano
2006-11-21 18:16     ` Herbert Poetzl
2006-11-22 13:46       ` Cedric Le Goater
2006-11-22 17:53         ` Eric W. Biederman
2006-11-22 22:56           ` Daniel Lezcano [this message]
2006-11-23  9:05           ` Dmitry Mishin
2006-11-22  8:21     ` Dmitry Mishin
2006-11-22  8:43       ` Eric W. Biederman
2006-11-22 13:23         ` Kirill Korotaev
2006-11-22 13:34         ` Dmitry Mishin
2006-11-22  9:55       ` Daniel Lezcano
2006-11-22 13:53       ` Cedric Le Goater
2006-11-22 16:41         ` Serge E. Hallyn
2006-11-22 16:55           ` Dmitry Mishin
2006-11-23  2:39             ` Serge E. Hallyn
2006-11-23  9:07               ` Dmitry Mishin
2006-11-23  9:24                 ` Cedric Le Goater
2006-11-22 16:57           ` Cedric Le Goater

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=4564D5B7.7030307@fr.ibm.com \
    --to=dlezcano@fr.ibm.com \
    --cc=akpm@osdl.org \
    --cc=clg@fr.ibm.com \
    --cc=dev@sw.ru \
    --cc=dim@sw.ru \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).