New "channels" feature in future version of Bird?
Hi, I am very curious about the new "channels" feature from the int-new branch. I understand it is supposed to replace import and export filters by connecting protocols to routing tables. What is the motivation for this change, and how does it work from a high-level perspective? Will it be part of Bird 2? Thanks, Baptiste
Hi! First of all, thank your for your question. It's good to know that the rework is really watched by the community.
I am very curious about the new "channels" feature from the int-new branch.
I understand it is supposed to replace import and export filters by connecting protocols to routing tables. What is the motivation for this change, and how does it work from a high-level perspective? Will it be part of Bird 2?
Import and export filters should stay as they were before. The "channels" feature is just an internal abstraction layer between routing tables and protocols. It was the best way chosen by us to allow protocols connect to several tables at once, like multiprotocol BGP. In the configuration, the only change worth mentioning is that your old config protocol bgp { table t1; import ...; export ...; igp table it; ... } should change to something like protocol bgp { ipv4 { table t1; import ...; export ...; }; ipv6 { table t2; import ...; export ...; }; vpn4 { ... }; igp ipv4 table it4; igp ipv6 table it6; ... } No replacing of filters is planned for the integrated version, at least in near future. If one of our crazy ideas comes true, we may add Lua as a possible language to write filters in (in several years' perspective) and maybe also deprecate the current, then-legacy filter language in far future. MQ
On Fri, Jun 17, 2016 at 01:40:45PM +0200, Jan Matejka wrote:
First of all, thank your for your question. It's good to know that the rework is really watched by the community.
I am interested in BGP multiprotocol support (to potentially implement a new NLRI), and it looks like a good idea to base this work on the integrated version.
Import and export filters should stay as they were before. The "channels" feature is just an internal abstraction layer between routing tables and protocols. It was the best way chosen by us to allow protocols connect to several tables at once, like multiprotocol BGP.
In the configuration, the only change worth mentioning is that your old config
protocol bgp { table t1; import ...; export ...; igp table it; ... }
should change to something like
protocol bgp { ipv4 { table t1; import ...; export ...; }; ipv6 { table t2; import ...; export ...; }; vpn4 { ... }; igp ipv4 table it4; igp ipv6 table it6; ... }
No replacing of filters is planned for the integrated version, at least in near future.
Great, thanks for the clear explanation! I was struggling with the new syntax, now it's clearer. It seems that the BGP part is not yet implemented? Also, the currently supported protocols (OSPF, radvd, RIP, static, kernel) only support one channel per protocol instance, is that done for simplicity? The new syntax is a bit contrived in this case, especially because the name of the protocol sometimes already defines the "protocol" (ipv4/ipv6). For instance with OSPF: protocol ospf { ipv6; area 0 {}; } → bird.conf, line 27: Different channel type protocol ospf3 { ipv4; area 0 {}; } → bird.conf, line 27: Different channel type Multiple channels per protocol instance would only be needed for Bird protocols that handle multiple "protocols" in the same instance (BGP, as in your example, or Babel). Thanks, Baptiste
On Fri, Jun 17, 2016 at 04:34:26PM +0200, Baptiste Jonglez wrote:
Great, thanks for the clear explanation! I was struggling with the new syntax, now it's clearer.
It seems that the BGP part is not yet implemented?
This is true, BGP is only partially implemented and not yet commited.
Also, the currently supported protocols (OSPF, radvd, RIP, static, kernel) only support one channel per protocol instance, is that done for simplicity?
Well, in some cases (OSPF, RIP, RAdv) there is no need for more channels. In other cases (static, kernel) it is currently for implementation simplicity, but it may change in the future.
The new syntax is a bit contrived in this case, especially because the name of the protocol sometimes already defines the "protocol" (ipv4/ipv6). For instance with OSPF:
This is true. Originally, i planned to have implicit 'default' channel in this cases, but conceptual simplicity won above simpler syntax. Also note that even if these protocols currently implies specific channel type (ipv4/ipv6/...), that may not be true in the future - there are standards for multiple address families in OSPFv3 (RFC 5838), RIPv2 also could support multiple AFs in principle (although AFAIK only IPv4 usage is specified) and even OSPFv2 has multi-topology options (but i doubt anyone will be bothered to implement them in BIRD).
protocol ospf { ipv6; area 0 {}; } bird.conf, line 27: Different channel type
protocol ospf3 { ipv4; area 0 {}; } bird.conf, line 27: Different channel type
Well, one sore point in the current syntax is that ospf2 and ospf3 are keywords for protocol types, which collides with implicit protocol naming (when no explicit protocol name is used, e.g. bgp1, bgp2, bgp3, ... for multiple BGP instances). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Fri, Jun 17, 2016 at 10:09:44PM +0200, Ondrej Zajicek wrote:
On Fri, Jun 17, 2016 at 04:34:26PM +0200, Baptiste Jonglez wrote:
Great, thanks for the clear explanation! I was struggling with the new syntax, now it's clearer.
It seems that the BGP part is not yet implemented?
This is true, BGP is only partially implemented and not yet commited.
Do you think it's in a state to be shared? I would like to base some code on MP-BGP, and I can help to adapt BGP to work with the integrated version.
Also, the currently supported protocols (OSPF, radvd, RIP, static, kernel) only support one channel per protocol instance, is that done for simplicity?
Well, in some cases (OSPF, RIP, RAdv) there is no need for more channels.
In other cases (static, kernel) it is currently for implementation simplicity, but it may change in the future.
The new syntax is a bit contrived in this case, especially because the name of the protocol sometimes already defines the "protocol" (ipv4/ipv6). For instance with OSPF:
This is true. Originally, i planned to have implicit 'default' channel in this cases, but conceptual simplicity won above simpler syntax.
I see, it makes sense.
Also note that even if these protocols currently implies specific channel type (ipv4/ipv6/...), that may not be true in the future - there are standards for multiple address families in OSPFv3 (RFC 5838), RIPv2 also could support multiple AFs in principle (although AFAIK only IPv4 usage is specified) and even OSPFv2 has multi-topology options (but i doubt anyone will be bothered to implement them in BIRD).
Interesting, thanks. I thought BGP and Babel were the only protocols capable of handling multiple AF.
protocol ospf { ipv6; area 0 {}; } bird.conf, line 27: Different channel type
protocol ospf3 { ipv4; area 0 {}; } bird.conf, line 27: Different channel type
Well, one sore point in the current syntax is that ospf2 and ospf3 are keywords for protocol types, which collides with implicit protocol naming (when no explicit protocol name is used, e.g. bgp1, bgp2, bgp3, ... for multiple BGP instances).
Wouldn't it be simpler to just allow the base keywork ("ospf", "rip") and use the channel type to decide which address family is implied? One disadvantage is that it won't be possible anymore when e.g. OSPF gains support for multiple AF.
On Fri, Jun 17, 2016 at 01:40:45PM +0200, Jan Matejka wrote:
If one of our crazy ideas comes true, we may add Lua as a possible language to write filters in (in several years' perspective) and maybe also deprecate the current, then-legacy filter language in far future.
YES!!! that would be awesome :) Kind regards, Job
On 06/17/2016 07:26 PM, Job Snijders wrote:
On Fri, Jun 17, 2016 at 01:40:45PM +0200, Jan Matejka wrote:
If one of our crazy ideas comes true, we may add Lua as a possible language to write filters in (in several years' perspective) and maybe also deprecate the current, then-legacy filter language in far future.
YES!!! that would be awesome :)
+many! That would be a total killer feature. \o/ Hans
On Fri, Jun 17, 2016 at 01:40:45PM +0200, Jan Matejka wrote:
Import and export filters should stay as they were before. The "channels" feature is just an internal abstraction layer between routing tables and protocols.
Hi I would disagree a bit here. Channels are not just an internal abstraction, they are explicit, user-visible concept representing connection between routing tables and protocols. Such connections always existed, but were implicit. In the int-new branch they are explicit. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Le 17/06/2016 à 13:40, Jan Matejka a écrit :
table it; ... }
should change to something like
protocol bgp { ipv4 { table t1; import ...; export ...; }; ipv6 { table t2; import ...; export ...; }; vpn4 { ... }; igp ipv4 table it4; igp ipv6 table it6; ... }
Look really good and clear syntax. The ability to use different table per family is really needed for mp-bgp and will be a killer feature.
No replacing of filters is planned for the integrated version, at least in near future.
If one of our crazy ideas comes true, we may add Lua as a possible language to write filters in (in several years' perspective) and maybe also deprecate the current, then-legacy filter language in far future.
Wow it was really a good idea. Even if the filter DSL is already good, lua open funny perspective (like dynamic filter using external source). It reminds me when a colleague write the first lua module for opensips. With this module we implement a very complex logic with ease. Can't wait :) -- Raphael Mazelier
On 17 Jun 2016, at 12:40, Jan Matejka <jan.matejka@nic.cz> wrote:
If one of our crazy ideas comes true, we may add Lua as a possible language to write filters in (in several years' perspective) and maybe also deprecate the current, then-legacy filter language in far future.
FWIW I did some work on hacking this in as a sort of filtering pipe. I ran up against a problem where I needed both a protocol and an instance of a protocol as separate things if I remember. This was a couple of years ago so I may have forgotten. The lua bit seemed easy enough. -- Alex Bligh
participants (7)
-
Alex Bligh -
Baptiste Jonglez -
Hans van Kranenburg -
Jan Matejka -
Job Snijders -
Ondrej Zajicek -
raf