Re: Thinking about "branes" for netbsd...

[Darren Reed <darrenr%netbsd.org@localhost>]

On 4/05/2012 3:41 AM, Gert Doering wrote:
> Hi,
> 
> On Thu, May 03, 2012 at 12:23:36PM -0400, Mouse wrote:
>>>>> [...] "processes get chroot'd into branes" [...]
>>>> I'm not even sure what it could mean, [...].  Perhaps something is
>>>> being extended metaphorically, but it's unclear to me what or how
>>>> that could be.
>>> "Give processes a different view to the network than 'the rest of the
>>> machine' has" - not that different to "give processes a different
>>> view to the file system", no?
>>
>> Yeah, but that involves (or, at least, I would expect that to involve)
>> more than just the routing table.  Or do branes cover more than just
>> routing?
> 
> I'm not sure how that particular bikeshed is planned, but I'd consider
> "IP addresses on Interfaces + Routing + Firewall rules" to be all I
> need to define a network environment.  If that's a "brane", I could
> very well see a process being "chroot()"ed into that.

That is my interpretation as well.

The proposal at this point in time has the following goals:
- make the kernel able to support different networking domains
- make it possible to manage those domains
- make it possible for processes to change domain into a brane

There is additional work required to:
- determine how and when to load the firewall configuration for a brane
- decide how to configure networking inside a brane (is there a
  library function using proplists or is there a script to run or...)

On 4/05/2012 3:43 AM, David Young wrote:
> The general idea is to have more than one forwarding domain per router.
> Belonging to each forwarding domain are the routes for that domain and
> some interfaces.  Each route/interface can belong to just one domain.
> Packets cannot cross from one forwarding domain to another except by
> going through an interface.  We can imagine a virtual interface that has
> two "ends," each end in a different forwarding domain, for shuttling
> packets from domain to domain.  More commonly we will have a hardware
> interface that attaches a NetBSD router's forwarding domain to the
> forwarding domain of a router/switch that's connected with an ethernet
> cable.

Except for the notion that a route can belong to one domain,
this is otherwise in agreement with what's proposed. More
than one domain may have a specific route, for example, two
domains may have the same default route.

> ISTM that it will be useful sometimes for a tunnel interface to straddle
> two domains, sending/receiving encapsulated packets on one domain and
> sending/receiving decap'd packets on the other.

And what if you have three domains?
Do you then need n-1 tunnels in each domain to route between them?
That doesn't scale.

> A forwarding domain at layer 2 is commonly called a VLAN.  We ought to
> replace bridge(4) with ethernet forwarding domains.

That needs careful thought but is not what I'd consider an important
problem to solve for the current proposal.

Further, if bridge(4) was to support TRILL then it may not make sense
to use VLANs.

... the topic of privileges is something that I'd like to avoid for
now, except to say that changing brane is like changing root - you
can only do it once.

Darren