<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">… and yet another followup … <div class=""><br class=""><div><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Seems simple and makes perfect sense. Will do.</span><br class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></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><br class=""></div><div>it didn’t make it into 2.0.2 and/or 1.6.4, though, right?</div><div><br class=""></div><div>(I’m sitting here in London still emitting lots of multicast RAs … 😩😩😩)</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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.<span class="Apple-converted-space"> </span><br class=""></blockquote><br class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">That is an interesting idea and also seems simple, although there are</span><br class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">some caveats, e.g. filters using such context-dependent-constants would</span><br class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; 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="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">It may be useful if you could make</span><br class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">a list of suggested constants.</span><br class="" style="font-family: Courier; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></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<span class="Apple-converted-space"> </span><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<span class="Apple-converted-space"> </span><i class="">birdc</i>. Again, naming conventions have to be observed, etc. and the manual must emphasize on<span class="Apple-converted-space"> </span><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<span class="Apple-converted-space"> </span><i class="">birdc</i> (or any other tool using the API), among many other possibilities. It would also be nice, if variables could hold<span class="Apple-converted-space"> </span><i class="">lists</i>, most notably prefix-lists of all sorts and AS/community lists. In this case the <i class="">birdc<span class="Apple-converted-space"> </span></i>interface would require<span class="Apple-converted-space"> </span><i class="">add</i>,<span class="Apple-converted-space"> </span><i class="">remove</i>,<span class="Apple-converted-space"> </span><i class="">list</i><span class="Apple-converted-space"> </span>functions in addition to<span class="Apple-converted-space"> </span><i class="">set</i><span class="Apple-converted-space"> </span>and<span class="Apple-converted-space"> </span><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><br class=""></div><div>Anything I can do from my side to help this along? ;-)</div><div><br class=""></div><div><br class=""></div><div>Aaaand, of course, here is another „thing“ I would like to see in future BIRD version:</div><div><br class=""></div><div>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><br class=""></div><div>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><br class=""></div><div>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><br class=""></div><div>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>(at least for the „direct“ static routes)</div><div><br class=""></div><div>Thanks,</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Clemens</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>(from the IETF-101 meeting in London)</div><div><br class=""></div><div><br class=""></div></div></div></body></html>