1 week until Summer of Code application time

[Hasso Tepper]

Simon 'corecode' Schubert wrote:
> I don't really see the benefit in this.  Either you combine forwarding
> tables into one table, or you... well, that's actually it.  I guess the
> larger part is more on a control plane level than on a data plane
> level, so that would more be a xorp project, I guess.  I might also
> miss the point completely.

Control plane is a trivial part, really. Forwarding plane part is much 
harder. Proper virtual router support as used nowadays massively (yes, 
really) in ISP's needs:

* Completely isolated forwarding tables (this includes L2 info) - you 
  just associate an interface with virtual router.

* Sockets associated with virtual router. A process can create a socket 
  listening 0.0.0.0:179 in particular virtual router only. Ideally some 
  mechanism to associate a process with virtual router - all sockets 
  created by process will be associated with this virtual router then.

* The ability to reuse IP addresses and TCP/UDP ports in virtual routers.
  Different virtual routers can have overlapping addresses and different 
  processes using overlapping ports.

* Mechanism to forward traffic between virtual routers (and full control 
  over the traffic).

With this in place, making control plane software to support it, is quite 
straightforward. I have done this once although in limited way on top of 
Linux forwarding tables (which are lame in routing point of view, btw) 
with Quagga.


regards,

-- 
Hasso Tepper