[prev in list] [next in list] [prev in thread] [next in thread]
List: bird-users
Subject: =?utf-8?Q?Re=3A_Making_a_wish_=2E=2E=2E_errr_=2E=2E=2E_*four*_wi?= =?utf-8?Q?shes!_=F0=9F=98=B3?=
From: Clemens Schrimpe <clemens.schrimpe () gmail ! com>
Date: 2018-03-23 11:40:36
Message-ID: C06B7615-608A-4CC8-8A77-0C7D851E1CFD () gmail ! com
[Download RAW message or body]
… 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)
[Attachment #3 (unknown)]
<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>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic