Felix programs IPIP tunnels

[mazdakn]

Description

Currently, it's BIRD that programs routes for IPIP encapsulation, which is unlike VXLAN|Wireguard where Felix programs the routes. This PR enables Felix to programs the IPIP routes as well, and not rely on BIRD anymore. The benefits are:

• Not needing an extra component (i.e. BIRD) for IPIP encapsulation. Enabling Felix to program IPIP routes and not running BIRD saves some memory/CPU.
• Allowing to get rid of Calico fork of BIRD (v1.6) which is way old. Instead we can use upstream BIRD.
• In future, we can also make Felix program no encap routes as well. and get rid of internal BGP mesh.

This PR includes:

• Adding support to Felix to program IPIP routes.
• Updating BIRD templates to not export IPIP routes, i.e routes with tunl0 interface.
• Updating BIRD templates to not program IPIP routes to kernel
• Introducing a new value of ipip for calico_backend variable to enable IPIP encapsulation without running BIRD. bird value still enables IPIP encapsulation and also start BIRD service.

Related issues/PRs

Todos

• Tests
• Documentation
• Release note

Release Note

TBD

Reminder for the reviewer

Make sure that this PR has the correct labels and milestone set.

Every PR needs one docs-* label.

• docs-pr-required: This change requires a change to the documentation that has not been completed yet.
• docs-completed: This change has all necessary documentation completed.
• docs-not-required: This change has no user-facing impact and requires no docs.

Every PR needs one release-note-* label.

• release-note-required: This PR has user-facing changes. Most PRs should have this label.
• release-note-not-required: This PR has no user-facing changes.

Other optional labels:

• cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.
• needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.

[caseydavenport]

Whooaaaa wasn't expecting this one. Sweet!

[fasaxc]

Had a very brief skim of the felix bits. Nice to see that it's not a crazy amount of code in Felix; as we'd hoped. Before looking in more detail/at the confd stuff it'd be good to understand the design a bit better:

• If I create a new cluster in non-bird mode it seems simple: I get felix routes and no BIRD.
• But what if I then decide to advertise routes later? Do we disable Felix routes in favour of BIRD? How do BIRD and Felix interact?
• Is there a way to get the exact old behaviour (i.e. disable Felix new function and let BIRD do what it always did)? I'd quite like to have that as an option in case folks are doing odd things that we don't know about! In simple cases, felix will program the same routes, but I bet some folks are peering with external nodes and doing IPIP with those external nodes!
• How is upgrade/downgrade handled? BIRD and felix will use different protocols on their routes, will Felix overwrite a BIRD route? Will Felix clean up a BIRD route that's now no longer needed? (Doing the latter would be easier once my big RouteTable refactor PR lands since there's a way to handle special cases like that.)

[fasaxc]

Does IPIP have the concept of a parent device? I thought that was a quirk of VXLAN. I'd expect that aspect not to be needed. Of course, if we do the IPIP device set-up in the background then we still need a kick channel but I don't think you need to send the parent device?

[mazdakn]

AFAIK, the parent device is needed to add routes to no encap routes. And for IPIP CrossSubnet we need to add no encap routes, right?

[frozenprocess]

looks related #5311