New "channels" feature in future version of Bird?

Ondrej Zajicek santiago at crfreenet.org
Fri Jun 17 22:09:44 CEST 2016


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 at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20160617/30c37fe0/attachment.asc>


More information about the Bird-users mailing list