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

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 5 May, 2012, at 07:32 , Darren Reed wrote:
> It would appear that various people did not fully read what I proposed
> or perhaps misunderstood it. What I wrote is that a brane would become
> an entire instance of networking and that global structures, etc, would
> disappear. If it helps you (or others) to understand it by thinking of
> branes in terms of support for virtual routers then I'm happy for you
> to do so but it is by no means limited to that.

The point was not that the mechanism should be thought of in terms of
a VRF implementation, it is only that the mechanism should not have arbitrary
constraints that prevent you from using it for a VRF implementation, or any
other job that the mechanism might be appropriate to use for.

> In that context, if a process belongs to a brane then all of its sockets,
> etc, would also belong to the new brane.

But, speaking of a topic that came up a week or two ago, what if the thing
I want to use the multiple tables for is to implement strict host behavior
on a multi-homed host?  That is, suppose I am running a server application
on a host with two interfaces, and I just want the reply packets to connections
that came in one or the other of the interfaces to go back out the same
interface (say the interfaces connect to different service providers).  Two
routing tables, one per interface, are required for this since the outbound
routing from the host needs to be done through a table that only has routes
pointing out the interface the packet needs to leave on.

For this to work I want my server process to be able to send and receive
packets in either brane (or, at least, using either table) at will.  In fact,
an ideal implementation might allow a single listening socket to receive
incoming connections from both tables (or branes, if you will), with only
the connected sockets generated by accept() ending up being tied to one or
the other table, since then the mechanism can be made transparent to the
application, though I guess opening a separate listening socket for each
table wouldn't be a huge burden.  None of this seems to work, however, if
the mechanism requires that the process needs to "belong to a brane", and
it is precisely this constraint in your proposal that I object to.  It gets
in the way of useful applications for the basic multiple-routing-table
mechanism.

The basic mechanism of multiple routing tables is a forwarding path mechanism.
It effects how and where packets are delivered by the kernel, but needn't
effect anything else.  The "process belongs to a brane" thing is an arbitrary,
additional constraint that may be useful for some applications of the
mechanism but which prevents it from being used for others, like a standard
VRF implementation (apparently what you are referring to as "virtual routers"
is not a standard VRF implementation) or the very simple strict host behavior
described above.  If you want the "brane" constraint unconditionally applied
in all cases I think you should justify why this constraint is so important
to preclude using the mechanism for other applications (including existing
ones) which are incompatible with the constraint.  Pretending such applications
don't exist really doesn't do this.

Dennis Ferguson