New "channels" feature in future version of Bird?

[Baptiste Jonglez]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20160620/1bceb0cf/attachment.asc>