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.