Filtering on Export-Protocol

[Clemens Schrimpe]

If I may chime in, briefly, here ...

This request relates to an "improvement suggestion" I made a few years back, but it was during the hot phase before 2.x was released, so I guess it was lost.

Back then I was asking for "context variables/constants", i.e. the peer's AS number in the context of a filter/function called from a BGP proto, etc.
One thing to solve with this approach would be, how to define these context-variables if you just wanted to manually execute a function/filter for testing, but that should be doable.

Ah ... just found the old mail, dubbed "Making a wish ... errr ... *four* wishes! 😳" from January 24th 2018 - I'll attach a copy of it to this one, just for reference. In it I already made a few suggestions re: potential candidates for such "context-variables".

Again, thanks for all the good work!

	Clemens

PS: The whole thread, back then, had a number of suggestions you gave a 🤔-maybe rating to ... i.e., "ipset protocol" and others ... interesting to see all these again. 😉

---- excerpt from previous mail exchange ----

>>> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20200409/05d2389d/attachment.htm>