mirrors/bird
mirrors/bird
0
0
Fork 0
mirror of https://gitlab.nic.cz/labs/bird.git synced 2024-12-22 01:31:55 +00:00
Code Releases Activity

Documentation: Updating roadmap as of end of 2024

Browse Source
This commit is contained in:
Maria Matejka 2024-12-03 12:29:30 +01:00
parent 707cad6188
commit b8008791cd
1 changed files with 156 additions and 208 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

364
doc/roadmap.md
View File

@ -1,109 +1,24 @@
# Project roadmap
## Planned for 2023
## Planned for 2025
### SNMP AgentX plugin for BIRD status export
Allow for easier status monitoring.
*Not decided yet.*
### BGP Monitoring Protocol (BMP)
BGP Monitoring Protocol (RFC 7854) is a protocol between a BGP speaker and
a monitoring node, which is notified about route updates and neighbor state
changes of the BGP speaker.
### Better coverage of automatic tests
Functionality tests should cover more possible configurations and
combinations. Integration tests should run automatically between different OS
versions and HW architectures. Experimental support for performance regression tests.
### Release 3.0-alpha1
Missing: MRT, merging
### Show BFD sessions details
CLI command showing detailed information about BFD sessions state
### Review and merge Babel extended next hop patches (RFC 9229)
Babel extension to allow IPv4 routes with IPv6 next hop. Patch on mailing list.
### Consolidate protocol statistics
Consolidate protocol statistics, make them useful for SNMP plugin and implement
'show XX stats' command.
### TCP-AO if it appears in Linux and BSD upstream
Resolve whether we should or shouldn't control the kernel key management.
Design and implement our side for both Linux and BSD.
### Conditional routes (v3)
Filters should be extended to allow conditional expressions based on a number of
matching routes in a routing table. This would allow to specify aggregate routes
using a static protocol and conditions like 'if there is at least 1000 routes
from this BGP protocol, accept this default route'. This feature comes handy
when a router needs to detect whether its BGP upstream is alive and working.
Based of number of routes received, the router can then announce or retract a
default route to OSPF, making multi-exit network routing simpler and more
effective.
### Aggregating routes
Requested by customer: aggregating multiple routes by a common set of attributes.
Implementation choice: the user specifies
EXPORT filter before aggregation AGGREGATE ON list of expressions to compare MERGE what to do with the remaining attributes
Example usage:
* aggregating information from multiple internal BGP routes into one external
* creating a multipath route from multiple BGP routes (currently done by MERGE PATHS)
* (in future) computing a minimal route set for kernel to make forwarding faster instead of writing the received full BGP set there
### PREF64 option in RA (RFC 8781)
Inform hosts about prefix used to synthesize NAT64 addresses. Requested in list:
http://trubka.network.cz/pipermail/bird-users/2022-November/016401.html
### Logging via UDP
Got a patch, probably never merged. May be useful.
http://trubka.network.cz/pipermail/bird-users/2022-January/015893.html
### BGP Tunnel Encapsulation Attribute (RFC 9012)
Packets sent to BGP next hop may be encapsulated using various tunnel
technologies. Useful for L3VPN.
### BGP AS Cones and ASPA support
Extend the RPKI protocol with AS Cones and ASPA loading. Implement AS Cones
and ASPA validation routines. There may be some pending patches from QRator.
### DHCPv6 relay agent
DHCPv6 relay agents (RFC 8415, RFC 8987) forward DHCPv6 messages between clients and
servers. They also ensure that prefixes delegated by DHCPv6-PD are routable,
i.e. they should generate routes for these prefixes.
### Nexthop attributes and ECMP filtering
Currently we have route attributes, but with ECMP routes it is necessary to
store per-nexthop data (like weight or encapsulation). We also do not have
proper way to manipulate with multiple nexthops from filters. Attributes should
be extended to allow per-nexthop ones and filters should be extended to allow
access multiple nexthops and their attributes.
### Performance accounting
Extended internal statistics about time spent in different modules of BIRD. If
the route server admin checks why it takes 15 minutes to converge, this should
give some basic info about performance. [MM: Internally needed by 3.0, already in progress]
### MPLS support
Finalize and merge improved MPLS infrastructure (including MPLS label allocator
and supporting code), improve its reconfiguration support and support for
segment routing.
### BGP Segment Routing Extension (RFC 8669)
Receive and announce Segment Identifiers (SIDs) for BGP next hops.
## Backlog for following years
## Expected features
*The order of these items is not significant.*
### Flowspec attribute filtering
Flowspec routes have many parameters, but these are not accessible from filters.
Filters should be extended to access all these attributes, but first it is
necessary to cleanup attribute handling in filters.
### EVPN / VXLAN extensions
There is an out-of-tree branch which we intend to continue work on and
eventually merge.
### Enhanced command-line interface
Most other vendors allow for updating the configuration from the command-line.
There is quite some demand to allow this with BIRD. Needs quite some refactoring
before possible.
### SNMP AgentX plugin for BIRD status export
Allow for easier status monitoring.
### BGP Optimal Route Reflection (RFC 9107)
Implement BGP best route selection on route reflectors to adhere to POV of
@ -114,59 +29,6 @@ Requested in list. May include lots of other RFC's as we have neglected this
feature for a long time.
http://trubka.network.cz/pipermail/bird-users/2022-January/015911.html
### IPv6 preference in documentation (?)
Address world's reluctance of legacy IPv4 deprecation by updating the
documentation in such a way that IPv6 is preferred and first seen.
### BGP local prefix leak prevention (?)
Reject local prefixes on eBGP sessions by default to prevent leaks to public Internet.
Unless explicitly enabled by config, of course.
### Re-bogonization of 240/4 legacy range (?)
We shouldn't believe that every operator does the
filtering right and they could simply rely on pre-2.0.10 behavior which
filtered this out by default.
### IPv4 multicast
Basic infrastructure for IPv4 multicast routing, including nettypes for
multicast routes and multicast requests, multicast kernel protocol and IGMPv2
protocol.
### PIM-BIDIR
Bidirectional PIM (RFC 5015) is a multicast routing protocol, variant of PIM-SM.
It uses bidirectional shared trees rooted in Rendezvous Point (RP) to connect
sources and receivers.
There is an old branch containing this. We should have merged this years ago.
### Improved VRF support
BIRD has working VRF support, but it needs improvements. VRF entities should be
first-class objects with explicit configuration, with a set of properties and
default values (like default routing tables, or router ID) for associated
protocols. Default kernel table ID should be autodetected. There should be
better handling of VRF route leaking - when a route is propagated between VRFs,
its nexthop should reflects that. Setup of VRFs in OS is out of scope.
### Linux kernel nexthop abstraction
Netlink allows setting nexthops as objects and using them in routes. It should
be much faster than conventional route update.
### Protocol attributes for filtering
Filters can access route attributes, but sometimes it could be useful to access
attributes of associated protocol (like neighbor-as or neighbor-ip for BGP
protocol). But it would require to have internal object model (below) first,
as we do not want to implement it independently for each protocol attribute.
### Mutable static routes
Extension to the static protocol that would allow to add/remove/change static
routes from CLI.
### Multipipe
Pipe-like protocol: When a route is exported to this protocol, it runs its
filter extended with capability to announce any number of new routes to any
table from one filter run. Its primary purpose is to allow user-specified
route aggregation and other non-linear operations.
### BGP minimum route advertisement interval (MRAI)
BGP specifies minimum interval between route advertisements for the same
network. This is not implemented in BIRD. It should be implemented for 3.0 to
@ -187,26 +49,8 @@ Label Distribution Protocol (RFC 5036) is a protocol for establishing
label-switched paths and distributing of MPLS labels between MPLS routers.
These paths and labels are based on existing unlabeled routing information.
### IPv6 multicast
Basic infrastructure for IPv6 multicast routing, including nettypes for
multicast routes and multicast requests, multicast kernel protocol and MLDv1
protocol. Most of these (with the exception of MLDv1) is just a variant of
IPv4 multicast.
### IGMP/MLD multicast proxy
A simple IGMP/MLD multicast proxy, which sends IGMP/MLD requests on a configured
uplink interface based on received requests on downlink interfaces, and updates
associated multicast routes.
### Source-specific multicast (SSM)
Infrastructure for multicasts should be extended to handle source-specific
multicasts. Extend multicast nettypes to include source addresses, handle them
in multicast kernel protocols and implement IGMPv3/MLDv2 protocols.
### PIM-SSM
PIM-SSM is a source-specific multicast routing protocol, a subset of PIM-SM
protocol (RFC 7761). It is restricted to source-specific multicasts, which
eliminates many problematic parts of PIM-SM.
### SRv6 support (RFC 8986)
Segment Routing over IPv6, SID assignments, Linux kernel support.
### Seamless BFD
New version of BFD negotiation defined in RFC 7880-7886 enables faster
@ -216,7 +60,71 @@ continuity tests by dissemination discriminators by the governing protocols.
To enable seamless maintenance of single links, OSPF can advertise such a link
getting down in advance, allowing to re-route. Defined in RFC 8379.
## Long-term
### IS-IS
IS-IS routing protocol is a nice-to-have alternative to OSPF.
### BGPsec
BGPsec (RFC 8205) is a new path security extension to BGP.
### BGP Link State extension
BGP-LS allows to transport information about network topology across BGP links.
This should help e.g. to run traffic-engineering between more confederated ASs.
Also needed to implement Seamless BFD on BGP: RFC 9247
### VPP / DPDK direct programming support
Module allowing to directly export routes to VPP, instead of playing ping-pong
with Netlink. Also possibly tighter integration, depends of user needs.
### Flowspec to kernel / VPP interface
BGP Flowspec are actually firewall rules, so either nftables or direct hardware
programming is what we need to execute them.
### Flowspec attribute filtering
Flowspec routes have many parameters, but these are not accessible from filters.
Filters should be extended to access all these attributes, but first it is
necessary to cleanup attribute handling in filters.
## Refactoring and internal plans
### Nexthop attributes and ECMP filtering
Currently we have route attributes, but with ECMP routes it is necessary to
store per-nexthop data (like weight or encapsulation). We also do not have
proper way to manipulate with multiple nexthops from filters. Attributes should
be extended to allow per-nexthop ones and filters should be extended to allow
access multiple nexthops and their attributes.
### OSPFv3 Extended LSAs
Implement RFC 8362. Needed for most of the newer OSPF features.
### Automatic performance testing
Integrated perftests into CI.
### IPv6 preference in documentation (?)
Address world's reluctance of legacy IPv4 deprecation by updating the
documentation in such a way that IPv6 is preferred and first seen.
### Improved VRF support
BIRD has working VRF support, but it needs improvements. VRF entities should be
first-class objects with explicit configuration, with a set of properties and
default values (like default routing tables, or router ID) for associated
protocols. Default kernel table ID should be autodetected. There should be
better handling of VRF route leaking - when a route is propagated between VRFs,
its nexthop should reflects that. Setup of VRFs in OS is out of scope.
### Linux kernel nexthop abstraction
Netlink allows setting nexthops as objects and using them in routes. It should
be much faster than conventional route update.
### Protocol attributes for filtering
Filters can access route attributes, but sometimes it could be useful to access
attributes of associated protocol (like neighbor-as or neighbor-ip for BGP
protocol). But it would require to have internal object model (below) first,
as we do not want to implement it independently for each protocol attribute.
### Interface and address table rework
The current state of two linked lists is becoming too limiting for certain use
cases. We are looking into conversion of these tables into some faster and
better accessible structures.
### Internal object model
We need to define explicit internal object model, where existing objects
@ -250,52 +158,92 @@ From Maria's notes:
* RFC 9254: YANG-CBOR mapping
* RFC 9277: Stable storage of CBOR (files)
## Perhaps
### IS-IS
IS-IS routing protocol is a nice-to-have alternative to OSPF.
### BGPsec
BGPsec (RFC 8205) is a new path security extension to BGP.
### PIM-SM
PIM-SM (RFC 7761) is a prevailing multicast routing protocol, but more
complicated than planned PIM-BIDIR and PIM-SSM.
Maybe, after generic configuration model is created, this may be a CORECONF
implementation.
### Netconf
Network Configuration Protocol (RFC 6241) is a XML/JSON protocol for
configuration management of network devices. It would benefit from generic
configuration model (above).
configuration management of network devices. This would be an overlay daemon
translating between XML (Netconf) or JSON (Restconf) and CBOR (Coreconf).
### NetConf overlay
Machine-friendly config file editor daemon (standalone) with standard NetConf
interface on one side and BIRD config file + reconfiguration requests on the
other side. Python3 seems to be better choice than C for this kind of work.
## Long-term thoughts
### Backend for 802.11r
Let's assume a bunch of boxes, all having some public wifi APs and some (secure) uplinks.
Design and implement an automatic backbone protocol to allow for simple almost-zeroconf
setup of e.g. a conference room or train / bus public wifi or even a local home network,
all with hostapd seamlessly transferring clients between APs via 802.11r.
Possible collab with Turris.
*We don't know whether we want this to be implemented in BIRD.*
### DHCP implementation
Ranging from DHCPv6 relay agents (RFC 8415, RFC 8987) to ensure that prefixes
delegated by DHCPv6-PD are routable, to actual full DHCPv6 (and DHCPv4) server
and maybe even a client.
### Configuring interfaces
There is a long rabbit-hole of what we allow ourselves to implement considering
the network interfaces. We have identified 4 different possible scenarios and
not decided on any of these yet.
0. we do nothing
1. we implement only what we really need (e.g. creating pseudo-interfaces for VXLAN)
2. we implement common things including interface address setting or changing its state
3. we go full NetworkManager
### LLDP implementation
Autodiscovery allowing also for autoconfiguration of other protocols.
### Wireguard routing support
The internal Wireguard routing is weird and we may want to explicitly route by
e.g. Babel in a complex network of tunnels. Or, if we decide to implement
interface configuration, we may even create interfaces based on whatever the
user configures.
### IPv4 multicast
Basic infrastructure for IPv4 multicast routing, including nettypes for
multicast routes and multicast requests, multicast kernel protocol and IGMPv2
protocol.
### PIM-BIDIR
Bidirectional PIM (RFC 5015) is a multicast routing protocol, variant of PIM-SM.
It uses bidirectional shared trees rooted in Rendezvous Point (RP) to connect
sources and receivers.
There is an old branch containing this. We should have merged this years ago.
### IPv6 multicast
Basic infrastructure for IPv6 multicast routing, including nettypes for
multicast routes and multicast requests, multicast kernel protocol and MLDv1
protocol. Most of these (with the exception of MLDv1) is just a variant of
IPv4 multicast.
### IGMP/MLD multicast proxy
A simple IGMP/MLD multicast proxy, which sends IGMP/MLD requests on a configured
uplink interface based on received requests on downlink interfaces, and updates
associated multicast routes.
### Source-specific multicast (SSM)
Infrastructure for multicasts should be extended to handle source-specific
multicasts. Extend multicast nettypes to include source addresses, handle them
in multicast kernel protocols and implement IGMPv3/MLDv2 protocols.
### PIM-SSM
PIM-SSM is a source-specific multicast routing protocol, a subset of PIM-SM
protocol (RFC 7761). It is restricted to source-specific multicasts, which
eliminates many problematic parts of PIM-SM.
### PIM-SM
PIM-SM (RFC 7761) is a prevailing multicast routing protocol, but more
complicated than PIM-BIDIR and PIM-SSM.
### BFD Multipoint Connectivity
Checking whether multiple "receivers" can communicate with a single "sender".
Possibly useful after merging PIM-BIDIR and implementing other PIMs. RFC 8562-8563.
### BGP Link State extension
BGP-LS allows to transport information about network topology across BGP links.
This should help e.g. to run traffic-engineering between more confederated ASs.
Also needed to implement Seamless BFD on BGP: RFC 9247
### Mutable static routes
Extension to the static protocol that would allow to add/remove/change static
routes from CLI.
### Locator/ID Separation Protocol
LISP intends to break up addressing to Routing Locators and Endpoint
Identifiers. This may help multihoming networks in future. RFC 9299-9306.
### Backend for IPv6 Multihoming without BGP
Implement and configure BIRD in such a way that local nodes are seamlessly
connected to the Internet via multiple upstreams, using Network Prefix
Translation and other techniques. Possible collab with Turris.
### Multipipe
Pipe-like protocol: When a route is exported to this protocol, it runs its
filter extended with capability to announce any number of new routes to any
table from one filter run. Its primary purpose is to allow user-specified
route aggregation and other non-linear operations.
## Minor