[prev in list] [next in list] [prev in thread] [next in thread]
List: bird-users
Subject: Re: Filtering on Export-Protocol
From: Clemens Schrimpe <clemens.schrimpe () gmail ! com>
Date: 2020-04-09 8:15:52
Message-ID: D663324D-6BDB-4294-9925-18C927B527D1 () gmail ! com
[Download RAW message or body]
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)
[Attachment #3 (unknown)]
<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>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic