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

[David Young <dyoung%pobox.com@localhost>]

On Fri, May 04, 2012 at 04:16:48PM +0800, Dennis Ferguson wrote:
> 
> On 4 May, 2012, at 01:43 , 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.
> 
> Okay, but maybe I can reword what I understand this to say in terms that
> (to me) more clearly describe mechanism.  It would be possible to configure 
> more
> than one route table for a protocol, with routes being added to, changed
> deleted from each table independently.  This actually requires replication
> of several address-bearing structures in addition to the route table (e.g.
> tables for PCB lookups), so let me call this group of structures a "routing
> instance".
> 
> The basic configurables around this are that each interface (or "interface",
> for some logical definition of this) in the machine running this network
> protocol needs to be told which of these tables it should use to route
> incoming packets, with the interface routes generated as a side effect
> of address configuration on that interface being stored in the same table.
> In addition, each open socket needs to be configured (or somehow come to
> understand) which table it should use to route outbound packets and
> which "routing instance" its socket binding should be stored in.  The
> collection of a routing instance, the interfaces configured to forward
> packets through and install routes in that routing instance and the
> sockets which are using the instance are what I think you are calling
> a "domain".

The collection you describe sounds like a domain to me.

> > 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?
> 
> The last question isn't rhetorical, either, since I know there are some
> VRF operations which require routes to be installed which work exactly
> like that (i.e. the next hop sends packets out an interface which is not
> part of the VRF the route is installed in) and I know there are other
> VRF operations where the result of one route lookup is to make it
> immediately do another route lookup in another table.  By not stopping
> at "I can configure this policy", but rather going all the way to
> "No other policy can possibly be configured" I think you make the
> mechanism less generally useful and I'd sort of like to see the
> justification for that.

You're right, it isn't desirable to be so restrictive.

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981