[Xorp-hackers] [PROPOSAL] Add 'virtual Vifs' to the FEA

[Bruce M Simpson]

After looking over the RIB code today, and much discussion with Pavlin, I
propose that we should implement a 'soft Vif'. This is an interface which
never actually gets pushed to the underlying ifconfig layer.

What's a soft Vif?
------------------

It's a Vif which exists in the FEA, but never, ever gets pushed to the
underlying kernel.

Why would we need such a thing?

 - We now represent discard routes within the RIB now as those whose Vif
   field points to a discard interface.

 - Such an interface has to exist within the FEA, but may not necessarily
   have a counterpart within the host's interface list.

  - Platforms where this is the case, at least for a 'discard interface':

    - Linux implements discards by adding routes of type RTN_BLACKHOLE
      to its FIB.

    - *BSD implements discards by adding routes whose RTF_BLACKHOLE
      flag is set; the gateway field must point to a loopback interface.

    - FreeBSD 5.x has its own discard interface disc(4), and does not
      need such hacks; but is backwards-compatible with the traditional
      BSD semantics, and doing it the old fashioned way may actually
      perform better as it can be picked up on the fast-forwarding path.

      - Unfortunately the administrator must explicitly configure an
        instance of disc(4), usually with an incantation along the lines
        of the following: 'ifconfig disc0 plumb'.

    - Click uses a Discard element.

Then the FtiConfig code for Linux and *BSD need only notice that the
vifname specifies a Vif with the is_discard() flag set, and do the
appropriate blackhole fandango.

The Ifconfig code would see that is_virtual() has been set on the
platform discard interface, and would not try to push it down to
the kernel. For other platforms with a 'real' software blackhole
interface, we can take advantage of that by not setting is_virtual.

So it seems to me that adding such things would protect the administrator
from having to know how the host platform implements blackholes within
the forwarding layer, and protect the RIB code from having to deal with
discards-implemented-as-interfaces as a special case.

It is worth nothing that Zebra kludges such a thing by hardcoding an
interface name Null0, as does Vendor C.

Rationale
---------

I don't see an easy way of supporting discards without considerably hacking
the RIB to do it, and we are still faced with the problem of pushing the
discard routes to the FEA. Treating discards as simple interface routes
sidesteps the problem, and would at least contain the ugliness to the FEA
itself and avoid layering violations.

The Vif field in IPRouteEntry cannot, for most intents and purposes,
be NULL. Adding the necessary special cases to the RIB looked to be much
more trouble than it's worth; we already have a notion of a 'connected
route', i.e. a route where the Vif is known and used. A DiscardNextHop
implies that the Vif/vifname is ignored for most intents and purposes.

Therefore, the use of DiscardNextHop only seems to be useful if it isn't
possible to assign an address to the interface used to blackhole packets,
for whatever reason.

So I'd like to regard DiscardNextHop as being a special case. Supporting
unnumbered interfaces (a la Vendor C) is a desirable feature, but for the
purposes of implementing discard routes, it is easier to consider it as
a separate problem to be addressed at a later date.

Thoughts/input requested... but time is wearing on and I'd like to
implement this so that it's done.

BMS