… and yet another followup …
>>> 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.
>
> Thank you. That was easy.
> (the next IETF meeting, where this could become be very useful, will be in
> mid-March … :-) :-) :-)
it didn’t make it into 2.0.2 and/or 1.6.4, though, right?
(I’m sitting here in London still emitting lots of multicast RAs … 😩😩😩)
>>> 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'.
>
> Yes, I had forgotten about this (very useful) feature. However, the syntax
> for this could be easily amended to allow the definition of such variables
> via the command line, i.e.,
>
> show route filter foo(a=1, b="bla", ...)
>
>> It may be useful if you could make
>> a list of suggested constants.
>
> Well ... here is what comes to mind easily:
> (NB: these are not the "names" of the variables I propose; we should come up
> with a good naming scheme once we settled on an initial list of variables)
>
> router id
> protocol name
> protocol type
> address family / channel-type
> local as
> remote as
> local interface name (outbound interface)
> local address (outbound interface)
> remote address
> external variables (see below)
>
> Variables, of course, only have values inside "useful" contexts, i.e, AS
> number inside BGP, etc. and are otherwise "undefined".
>
> I'l also like to propose the introduction of global variables (vs. existing
> constants), which can be set in the configuration file, via the command-line
> (i.e., "bird -D foo=42" and at runtime via birdc. Again, naming conventions
> have to be observed, etc. and the manual must emphasize on when exactly
> filters are evaluated and such.
>
> But this would allow to build a config, whose behavior could be altered at
> runtime, i.e., start-up in "test-mode" and then later be switched over to
> "production-mode" through birdc (or any other tool using the API), among many
> other possibilities. It would also be nice, if variables could hold lists,
> most notably prefix-lists of all sorts and AS/community lists. In this case
> the birdc interface would require add, remove, list functions in addition to
> set and delete.
> (yeah, I know ... way more things to specify here, like uniqueness, order,
> etc. -- I'll hold back until you promise not to shoot down this idea
> completely ;-)
> Also: Can filters/functions set,add,remove,delete variables too ... oh, my
> /o\ ...) - would be nice, so one could easily implement one's own status
> counters ...
>
Anything I can do from my side to help this along? ;-)
Aaaand, of course, here is another „thing“ I would like to see in future BIRD
version:
As the times where one would have proper link-state on circuits carrying up- or
downstream BGP are clearly over these days, one would/should consider using BFD
instead to determine reachability of one’s peer. However: Many ISPs
(„Carriers“) do not support thus due to lameness, stupidness or other means of
inability.
So: Can we have a very simple „ping“ functionality, which could fulfill BFD’s
role in such cases? Like „ping every second, if three pings in a row went
missing consider the link down!“.
That would also be tremendously helpful for „simple“ (dumb) ISPs links who
aren’t using any routing protocol at all („just point a default route at out
router“) to „verify“ a static default route.
If „ping“ gives you the creeps for one reason or another, can we use an „ARP
state“ (for the peer’s address) instead?
(at least for the „direct“ static routes)
Thanks,
Clemens
(from the IETF-101 meeting in London)
