Merging bird and bird6

Alexander V. Chernikov melifaro at ipfw.ru
Thu Jul 7 13:12:15 CEST 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ondrej Zajicek wrote:
> On Thu, Jul 07, 2011 at 01:09:48AM +0400, Alexander V. Chernikov wrote:
>> Hello list!
>>
>> Are there any plans to move from different daemons to single one?
>>
>> From user point of view:
>> We will live with both v4+v6 for the next 10+ years, having all dynamic
>> routing in single place with single CLI is much more convenient.
>>
>> From developer point of view:
>> At the moment all code is based on ip_addr address type which is defined
>> to be v4 OR v6 at compile time. FIBs API assume the same: IPv4 OR IPv6.
> 
> My idea [*] about the future of IPv4/IPv6 split is to allow IPv4
> addresses be embedded in IPv6 ip_addr (probably using IPv4-mapped
> address prefix). That would allow integration with minimal changes
> (probably just some UI changes, some FIB integration and some tricks
> with dual compilation of one-AF protocols).
> 
> Bird4 would still be IPv4-only (with ip_addr of size 4 B) mainly for
> users with big route server deployments, but bird6 would support both
> IPv4 and IPv6.
> 
> Is this model consistent with your requirements / way of development?
It depends on FIB/tricks implementation :)
Actually, I'm trying to discuss those implementation details.

At the moment we have at least the following non-standard things in the
world of routing:
* VPNv4 address family (RFC 4364) (8-bytes route distinguisher, 4 byte
IPv4 address)
* VPNv6 address family (RFC 4659) (8-byte route distinguisher, 16 byte
IPv6 address)
* MPLS address family (RFC 3032) (size varies, it may be 16 bytes or
more since  label stack depth is implementation-specific. for example,
sizeof(sockaddr_mpls) is ~80 bytes for my implementation)

First two are purely BGP (RR or MPLS VPN PE client) internal tables and
can be rolled within BGP protocol only. MPLS is more tricky since it
operates numbers (labels) instead of IP addresses. additionally, label
is only a key to another data (action and label stack to be imposed). We
also need to install it to kernel somehow. For kernel it us just usual
sockaddr structure, but passing it to krt_* function is not so easy.

I'm thinking about a bit more general approach for FIB tables:
All the time (except sh route CLI command) we need exact match only.

If, for example, we:
* introduce fib2_* (or mpfib_*) api specifying address family and
sizeof() for "address"
* use pointers instead of passing arguments by value in (at least fib2_*
api) and all protocol hooks
* do compare by memcpy() for searching (and use AF-dependent hash based
on value passed in _init)

life will be easier for non-IPv4/IPv6 AF and the first step towards
ipv4+ipv6 merge will be done

> 
> [*] originally suggested by Martin Mares.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4VlI8ACgkQwcJ4iSZ1q2mnigCdHOMAnFIntZ/BJ+U7cuFalnZr
v4gAnjeY00dyTicAxx1YVpRCqzuvm1hL
=bP8v
-----END PGP SIGNATURE-----



More information about the Bird-users mailing list