Making a wish ... errr ... *four* wishes! 😳

[Ondrej Zajicek]

On Wed, Jan 24, 2018 at 09:15:36AM +0100, Clemens Schrimpe wrote:
> Gentlepeople (especially those from the BIRD development team) -
> 
> being an avid BIRD user for some time now I always kept a small list of
> „it would be nice, if …“-things for BIRD 1.x, which I kept for myself, as
> I knew BIRD 2.x was in the works (and thus people were busy already…),
> but now I get the feeling, that 2.x is slowly stabilizing and I’d like to
> put them on the table for open discussion:

Hello

First, i am glad for such feedback and feature suggestions. It is nice to
get more user feedback than just bugreports (although i do not want to
downplay importance of bugreports ;-)).


> Simple things, a.k.a. low hanging fruits:
> 
> (Optional) unicast replies to IPv6 RS
> 
> As one of my many uses for BIRD is in large wireless environments (i.e., IETF meetings) I am very interested in keeping the amount of multicast traffic as low as possible. The standards allow for a router to (immediately) respond with a unicast RA to an RS as an alternative to sending out a multicast RA „some (short, random) time“ after receiving an RS. Many others (Juniper, et.al.) have implemented this and I’d like to see this in BIRD too. The code changes are apparently very simple, so I almost did it myself, but then I didn’t want to interfere with ongoing 2.x developments.
> (lame excuse, I know …)

Seems simple and makes perfect sense. Will do.


> Context dependent (global) „variables“ for functions/filters
> 
> I (and probably others too) would really enjoy having more global variables defined for use inside filters & functions, depending on the context within which the respective filter/function is being called. The most obvious ones would be the peer’s (and our own) AS number (in the context of BGP protocols), the filtering direction, the protocol (type and name), the next hop’s address (where applicable), and so on.
> 
> Yes, I know, most of these could be explicitly given (at least to a function) when calling it as the import/export filter for a protocol with a „where“ clause, but that would defeat the purpose of using templates (which I really do like and use a lot).
> 
> The general concept of having „globals“ inside functions/filters is already there - just presently only in the context of the route that is being evaluated. I’d like to see this expanded into other contexts as described above. 

That is an interesting idea and also seems simple, although there are
some caveats, e.g. filters using such context-dependent-constants would
probably work for 'show route filter'. It may be useful if you could make
a list of suggested constants.


> More „controversial“ things:
> 
> Maintain interface addresses (Linux et.al.)
> 
> It would be nice, if BIRD could be „enhanced“ [sic] to take care of addresses assigned to interfaces, i.e. establish them in the first place and afterwards maintain them, i.e., re-install static, global IPv6 addresses on interfaces, which have suffered a link-state bounce.
> The latter is particularly interesting, since Linux -by design- removes global IPv6 addresses from an interface during a link-down state transition.
> 
> Rationale: The various Linux distributions have all sorts of (different and sometimes „funky“) implementations of how to establish addresses to interfaces in the first place and then „deal with them“ during link-state state changes. I would like to have BIRD take care of this relatively simple task as well as the way more complicated task of maintaining millions of routes. If only to have a clean way to define „a router“ within one system (BIRD) as opposed to „get the addresses onto the interfaces with a bunch of iproute2 commands and then start BIRD to take care of the rest“-approach I’ll have to use now. A simple „boot the machine and fire up BIRD - done“ one-stop-shopping solution, if you may.
> 
> This is particularly interesting to smaller, dedicated routers, like (former) OpenWRT platforms, Raspberry Pis - or (my application) Ubiquiti routers of all shapes and sizes, where I presently replace the built-in Quagga Version with BIRD. Speaking of Quagga: It takes care of interface addresses too, you know … ;-)

I have mixed feelings about that. On one hand, i would like such
functionality, on the other hand, it is hard to defend a reason to
integrate it to BIRD instead of being completely independent daemon,
so it seems like creeping featurism. On the third hand, the same
could be said for RAdv and it is still part of 'network management'
domain.

Also i would say that while it may seem like a relatively simple task
compared to maintaining of kernel routing tables, the later one is more
well-bounded, while the former may expand to more and more feature
requests. It starts with setting the addressess to interfaces, continues
with ifrename-like functionality and interface creation (as all these
VLANs and bridges do not create themselves) and ends with DHCP/SLAAC
clients and hooks for external commands.

I though about this feature in the past and over time, i changed my
optinion about it from 'probably no' to 'perhaps sometimes'.


> An „ipset“ protocol for Linux
> 
> It would be tremendously helpful to have a protocol, which would maintain given (named) „ipset <http://ipset.netfilter.org/>“ tables on Linux. This would allow for very easy interactions with iptables-based ACLs on Linux platforms. It should/could be treated like a Linux route-table, just with less/different attributes. So it should „sync“, could possibly „import“ items from the ipset, could be made „persistent“, etc.
> 
> Applications are numerous: From fully automatic BCP38 handling at border interfaces to (again, fully automated) suppression of bogon traffic, to statistical analysis, to … whatever. It would be a single, well defined tool to interact with the whole world of capabilities the iptables/ipsets world offers.

That is something i would have but not yet managed to get to implement it.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."