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

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

On 5 May, 2012, at 11:22 , Darren Reed wrote:

> Dennis Ferguson wrote:
>> 
>>> Packets cannot cross from one forwarding domain to another except by
>>> going through an interface.
>> 
>> And this is a place where I stumble.  If you want to implement a
>> policy which prevents packets from crossing from one domain to another
>> except by going through an interface (and if I understand what that
>> means), why is it not sufficient that you can configure each of these
>> tables with routes which only route packets from one domain to the other
>> via an interface?  Why is it necessary to go the extra step and prohibit
>> someone else from installing a route in one table with a next hop which
>> directly routes out an interface whose inbound packets are forwarded via
>> another table (i.e. an interface in another domain), if that is what is
>> required for that someone else to get their work done?
> 
> To allow cross references between data structures from one brane to
> another or cross talk where packets can move from one brane to another
> would be a very dirty implementation. The goal of branes is to support
> network virtualisation. One aspect of network virtualisation is the
> ability for the kernel to support multiple routing tables as a result.

I learned a long time ago that there is no accounting for taste, and
what looks to me like dirt is often someone else's very excellent and
essential feature.  While the goal of branes might be network virtualization
that is only one of many possible applications for multiple forwarding
tables, so it is bothering me a bit that you seem to want to implement
multiple forwarding tables in a way which excludes those other applications
rather than designing a more general underlying implementation of the
multiple forwarding table mechanism, and then figuring out how to specialize
that when network virtualization is the particular application you want to
use it for.  A standard VRF implementation needs the above, and also needs
to have a single routing application able to populate multiple forwarding
tables (since the installation of a route in one table often has implications
for others). This might not be to my taste either, yet I see no reason
to implement 98% of the mechanism essential to this application but
deny it the remaining 2% because your application doesn't want to do that.

> In terms of implementation, can you imagine the locking hell that would
> result if it you tried to directly join both of those domains because
> one wanted to use the resources of another?

Now this part is interesting.

Let me just assert that, while I find talking about "branes" and multiple
forwarding tables in general personally interesting, this is a geeky
feature that the average user of NetBSD is probably almost never going
to use since they'll almost never have one of the problems that this
mechanism solves (and the more you constrain it, the less likely it is
they'll have a problem this is fit for).  What those users are far more
likely to be using, however, is multiprocessors, since it is getting
harder all the time to buy CPUs that don't have multiple cores.

This being the case, I think "branes" just can't be the solution for
the NetBSD network stack's SMP problems because the majority, who have
SMP systems but absolutely no problems with networking requiring multiple
forwarding tables, need a network stack which makes good use of an SMP system
even when they only have use for a single forwarding table.  The SMP problems
must be solved in a way which does not depend on this, and are a far higher
priority than this.  Because of this, I think it is far too early to make
declarations about what operations are or aren't going to be locking problems,
since the big lock has to go regardless of branes.

Dennis Ferguson