[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Thinking about "branes" for netbsd...
Dennis Ferguson wrote:
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.
I think you misunderstand what I'm proposing. What I'm proposing is
to implement virtual networking stacks for NetBSD - aka branes. It
just so happens that doing so delivers the ability to maintain
independent routing tables. I am not trying to solve the virtual
routing table problem. This goal has been recognised as needing to
be solved for NetBSD. There is nothing saying that you have to use
branes to solve your virtual routing problems but similarly, they
are not defined as being part of the problem that needs solving
for virtual networking stacks in NetBSD and nor should they be.
If you were willing to come up with a virtual routing table
implementation then I'm pretty sure that it would work just
as well with branes as it would without them. The problems that
need to be solved for virtual networking stacks are at a different
level to those of virtual routing tables. The routing table (or
tables) are just one piece of the networking stack that needs to
be made brane aware.
Main Index |
Thread Index |