Add ProjectCalico to eBPF projects page

[bcreane]

Add ProjectCalico to eBPF projects page. In terms of requirements for inclusion in the projects page:

• The project must be open source: ✅ please refer to Project Calico's license model.
• The project must be using eBPF as its underlying core technology: ✅ Project Calico is built around our robust eBPF data plane with critical eBPF-only features such as source IP preservation, and direct-server-return.
• The project must be open to collaboration: ✅ Project Calico's open source contributors (100+) reflect a highly involved open source community. See contributors.
• The project must be actively maintained. ✅
• The project must be used in production-like environments with a significant amount of users. ✅ Project Calico has + 1 billion docker image pulls which speaks to it's prevalence: Calico node docker image pulls.

[netlify[bot]]

✔️ Deploy Preview for ebpfio ready! Built without sensitive environment variables

🔨 Explore the source changes: c12df40d3f8a334e173f7fbd0ceb855a8d4503d1

🔍 Inspect the deploy log: https://app.netlify.com/sites/ebpfio/deploys/620be7ced38182000827fd43

😎 Browse the preview: https://deploy-preview-166--ebpfio.netlify.app

[borkmann]

• The project must be using eBPF as its underlying core technology: white_check_mark Project Calico is built around our robust eBPF data plane with critical eBPF-only features such as source IP preservation, and direct-server-return.

The actual full quote of the requirement is: The project must be using eBPF as its underlying core technology, in other words, a project would lose its purpose if the eBPF parts are removed. Looking at the project, you maintain 4 different dataplanes in parallel, that is, standard Linux (netfilter/iptables) which is the default one, eBPF, Windows HNS and VPP. Looking at eBPF dataplane limitations, it seems to lack fundamental things like IPv6 support in year 2022. Users need to manually install kernels on cloud providers in order to use the project's eBPF dataplane. Moreover, the latter is only regarded as an alternative and not a full replacement of your standard Linux iptables dataplane (otherwise the eBPF dataplane would be the default one). All that said, this does not qualify to be listed as "major" eBPF application, it could be "emerging" one at best.

• The project must be used in production-like environments with a significant amount of users. white_check_mark Project Calico has + 1 billion docker image pulls which speaks to it's prevalence: Calico node docker image pulls.

You are saying that the 1 billion docker image pulls refer to eBPF dataplane users?

[bcreane]

Hi @borkmann , thanks for the comments. I'm a bit confused about the standards, I'm hoping you can help me here. I see, for example, that Falco is listed as a "major" eBPF project, but clearly it's possible to deploy Falco w/o eBPF, per https://falco.org/blog/choosing-a-driver/.

Regarding the billion pulls, we don't have a way to disaggregate open source users by data plane, however Calico's #eBPF slack channel currently has 3,521 users.

While reviewing past additions to the "landscape" page, it's clear there isn't a standard set of metrics that submitters supply to justify inclusion, e.g. https://github.com/ebpf-io/ebpf.io/pull/136 is just a screen grab describing the project. I'm open to providing more reasoning/justification for including Project Calico on the eBPF page, but I think maintainers would need to be clear about the requirements and apply them evenly across submitters.

Looking forward to continuing this discussion, thanks again @borkmann .

[frozenprocess]

Hey @borkmann and @dthaler This seems to be stuck in a limbo. Could you please provide guidance on how to overcome this roadblock so we can also share our eBPF efforts with the community?

[frozenprocess]

The actual full quote of the requirement is: The project must be using eBPF as its underlying core technology, in other words, a project would lose its purpose if the eBPF parts are removed. Looking at the project, you maintain 4 different dataplanes in parallel, that is, standard Linux (netfilter/iptables) which is the default one, eBPF, Windows HNS and VPP.

In eBPF mode, Calico's eBPF dataplane forms the core of the program (Calico is modular :tada: ). If the eBPF capabilities are removed from the underlying host, or the eBPF core is damaged , or the eBPF code is attacked by a hammer, the program will cease to function which is exactly what is stated as the requirement: The project must be using eBPF as its underlying core technology, in other words, a project would lose its purpose if the eBPF parts are removed.

Looking at eBPF dataplane limitations, it seems to lack fundamental things like IPv6 support in year 2022.

I apologize, but it is difficult for me to understand the issue being raised as it appears to be based on a personal perspective. I do not see a list of fundamental requirements or a credible source that links the absence of an unrelated networking topic for determining a project's placement :confused:. Based on my understanding, these are the requirements.

https://github.com/ebpf-io/ebpf.io-website/blob/8785ce4e5f4d0bf2e71277fbb209ed0504611bfc/src/common/projects/Faq.js#L34-L63

Users need to manually install kernels on cloud providers in order to use the project's eBPF dataplane.

I believe the information on that page may be outdated as AWS has updated its Linux image. However, the purpose of that page seems to be toward educating the community on the relationship between eBPF and the Linux Kernel before implementing it.

Moreover, the latter is only regarded as an alternative and not a full replacement of your standard Linux iptables dataplane (otherwise the eBPF dataplane would be the default one).

I think there might have been a misunderstanding. Calico offers multiple dataplanes, and the term "alternative" is used frequently. The Calico documentation refers to Standard Linux as the default since most tutorials aim to provide the highest level of compatibility for all users.

It's worth noting that all projects aim to provide some level of compatibility with technologies other than eBPF to ensure that their solution works in all environments. While the approach and language used might be different, all seems to have the goal to provide their community the best possible experience.

For example, the following sentence indicates that in some cases even Cilium uses iptables.

Depending on the Linux kernel version being used, the eBPF datapath can implement a varying feature set fully in eBPF. If certain required capabilities are not available, the functionality is provided using a legacy iptables implementation. See [:ref:`features_kernel_matrix`](https://github.com/cilium/cilium/blob/master/Documentation/network/ebpf/iptables.rst#id1) for more details.

original here.

To clear things up as much as possible, the full paragraph in the blog which was mentioned by @borkmann, continues to show compatibility is a key.

While the standard data plane focuses on compatibility by working together with kube-proxy and your own iptables rules, the eBPF data plane focuses on performance, latency, and improving user experience with features that aren’t possible with the standard data plane.

The second part of the statement shows what is not possible with the standard linux dataplane hence why someone should switch to Calico's eBPF dataplane. I believe the goal of that blog is to not force people into using a technology that they might not fully understand, but to educate and empower them so they can make informed decisions.

All that said, this does not qualify to be listed as "major" eBPF application, it could be "emerging" one at best.

I believe that the statement, "that Project Calico and its eBPF dataplane does not qualify" to be listed in the "major" section of eBPF.io is unfair since the project meets all the written criteria that are listed as necessary to be considered a "major" eBPF application.

I hope this will be able to get the ball rolling.

[borkmann]

@frozenprocess Thanks for clarifying some of the above points. Could you do a rebase? One thing that is missing in the project description of your PR is how eBPF is used. Please take a look at some of the other text descriptions as examples https://ebpf.io/applications#major-applications so would be good to add something more concrete.

[borkmann]

Superseeded by https://github.com/ebpf-io/ebpf.io-website/pull/349