crest at rlwinm.de
Thu Dec 8 18:34:27 CET 2016
On 08/12/2016 18:19, Israel G. Lugo wrote:
> On 12/08/2016 04:42 PM, Martin Mares wrote:
>> Hello, world!\n
>>> I think that we should expand static protocol to allow adding or deleting
>>> routes interactively. There are some problematic behavioral details in
>>> it; e.g., how we should handle interactive removal of a route from
>>> configuration. Should we have two independent sets of routes, one
>>> added/removed by reconfiguration, one interactively? Or should we allow
>>> to remove interactively one from configuration? If so, should it respawn
>>> during reconfiguration?
>> Maybe define a separate protocol which exports routes added/removed online?
> I really like this idea! A protocol called "interactive" or "runtime" or
> somesuch. It keeps the configuration clean, without having to complicate
> the static protocol, or having strange unintuituve behaviors. The
> "interactive" protocol would only have routes learned online, so its
> behavior is well defined. On bootup it has no routes, and during the
> lifetime of Bird, it will learn or forget routes manually through the
> CLI or other APIs. A few new CLI/API commands, to "add", "remove" and
> "clear". This makes the question of reconfiguration simple: it should
> not touch the "interactive" routes. If the user wants to clear them he
> will use the "clear" command at runtime.
As long as each "record" is at most 512 bytes the protocol could just
offer a named pipe to add new records. That would be crude because there
is simple way to acknowledge writes, but trivial to interface with. A
better way would be to replace the pipe with a unix domain sequential
packet socket and simple protocol to report success/failure.
More information about the Bird-users