<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">If I may chime in, briefly, here ...<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class="">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.</div><div class=""><br class=""></div><div class="">Ah ... just found the old mail, dubbed "<i class="">Making a wish ... errr ... *four* wishes! </i><span style="font-style: normal;" class="">😳</span>" 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".</div><div class=""><br class=""></div><div class="">Again, thanks for all the good work!</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Clemens</div><div class=""><br class=""></div><div class="">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. ðŸ˜‰</div><div class=""><br class=""></div><div class="">---- excerpt from previous mail exchange ----</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="">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.<br class="">(lame excuse, I know â€¦)<br class=""></blockquote><br class=""><span class="" style="float: none; display: inline !important;">Seems simple and makes perfect sense. Will do.</span><br class=""></div></blockquote><div class=""><br class=""></div>Thank you. That was easy.</div><div class="">(the next IETF meeting, where this could become be very useful, will be in mid-March â€¦ :-) :-) :-)</div></div></div></blockquote><div class=""><br class=""></div><div class="">it didn’t make it into 2.0.2 and/or 1.6.4, though, right?</div><div class=""><br class=""></div><div class="">(I’m sitting here in London still emitting lots of multicast RAs â€¦ ðŸ˜©ðŸ˜©ðŸ˜©)</div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="">Context dependent (global) â€žvariables“ for functions/filters<br class=""><br class="">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.<br class=""><br class="">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).<br class=""><br class="">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. <br class=""></blockquote><br class=""><span class="" style="float: none; display: inline !important;">That is an interesting idea and also seems simple, although there are</span><br class=""><span class="" style="float: none; display: inline !important;">some caveats, e.g. filters using such context-dependent-constants would</span><br class=""><span class="" style="float: none; display: inline !important;">probably work for 'show route filter'.</span></div></blockquote><div class=""><br class=""></div><div class="">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.,</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;">     </span>show route filter foo(a=1, b="bla", ...)</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class="" style="float: none; display: inline !important;">It may be useful if you could make</span><br class=""><span class="" style="float: none; display: inline !important;">a list of suggested constants.</span><br class=""></div></blockquote><div class=""><br class=""></div><div class="">Well ... here is what comes to mind easily:</div><div class="">(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)</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">router id</li><li class="">protocol name</li><li class="">protocol type</li><li class="">address family / channel-type</li><li class="">local as</li><li class="">remote as</li><li class="">local interface name (outbound interface)</li><li class="">local address (outbound interface)</li><li class="">remote address </li><li class="">external variables (see below)</li></ul><div class=""><br class=""></div><div class="">Variables, of course, only have values inside "useful" contexts, i.e, AS number inside BGP, etc. and are otherwise "undefined".</div><div class=""><br class=""></div><div class="">I'l also like to propose the introduction of global <i class="">variables</i> (vs. existing <i class="">constants</i>), which can be set in the configuration file, via the command-line (i.e., "bird -D foo=42" and at runtime via <i class="">birdc</i>. Again, naming conventions have to be observed, etc. and the manual must emphasize on <i class="">when exactly</i> filters are evaluated and such.</div><div class=""><br class=""></div><div class="">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 <i class="">birdc</i> (or any other tool using the API), among many other possibilities. It would also be nice, if variables could hold <i class="">lists</i>, most notably prefix-lists of all sorts and AS/community lists. In this case the <i class="">birdc </i>interface would require <i class="">add</i>, <i class="">remove</i>, <i class="">list</i> functions in addition to <i class="">set</i> and <i class="">delete</i>.</div><div class="">(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 ;-)</div><div class="">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 ...</div><div class=""><br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Anything I can do from my side to help this along? ;-)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Aaaand, of course, here is another â€žthing“ I would like to see in future BIRD version:</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">So: Can we have a <i class="">very simple</i> â€ž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!“.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">If â€žping“ gives you the creeps for one reason or another, can we use an â€žARP state“ (for the peer’s address) instead?</div><div class="">(at least for the â€ždirect“ static routes)</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;">      </span>Clemens</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>(from the IETF-101 meeting in London)</div></div></div></div></body></html>