Cilium Feature Proposal

Problem

In IPv4 and dual-stack environments, the Cilium BGP Control Plane derives the Router ID from the IPv4 address assigned to the node. However, in the IPv6 single-stack environment, there's no IPv4 address to use, so users must specify the Router ID manually for each virtual router for each Node.

$ kubectl annotate node <node-name> cilium.io/bgp-virtual-router.64512="router-id=10.0.0.1"

This is a big operational overhead because users must manage the assignment by themselves.

Proposed Solution

User Interface

The basic idea is to provide a pool of Router IDs like 10.0.0.0/16 in advance, and the Cilium Operator manages the assignment as we do for the IPAMs. A design decision we need to make here is how to provide the Router ID.

Option1: Via Helm configuration

Provide Router ID pool through Cilium operator's configuration like bgpControlPlane.routerIDPool=10.0.0.0/16 which will ultimately rendered as a cilium-config ConfigMap entry. This is easy to implement, but changing or extending the range requires operator restart.

Option2: Via CRD

We can either extend CiliumBGPPeeringPolicy or introduce another CRD like CiliumBGPRouterIDPool and provide a Router ID from there. It's more complicated in terms of the implementation, but adding/deleting a range can be done dynamically without operator restart.

In my personal opinion, option 1 should be enough for most cases because the uniqueness of the Router ID needs to be guaranteed only within AS these days RFC6286. Thus, it's easy for operators to allocate a large range. Also, it is possible to start from option 1 and support option 2 later.

Retaining Router ID over restart

The operator and agent must retain the Router ID over restart. This is important for Graceful Restart. In some implementations, when the Router ID of the restarting node changes, the Graceful Restart fails.

The operator can persist the assignment by writing assigned Router ID to either CiliumNode object or CiliumBGPNodeConfig object in BGP Control Plane v2.