Definition of a CNF

[jeffsaelens]

I think this is one of the first problems we need to tackle collectively. As we start making claims on what is or isn't a best practice, we need to ensure there is a distinction of what pod/container is responsible for. Blanket statements without context could get us in trouble, and so we should specify when a best practice is for an infrastructure container, a CNF or generic app. For us to make this distinction, we need to first have a definition of what a CNF is (to provide context to the containers that make it up).

Claims like "no privileged containers" as a best practice is sensible in a lot of cases, but not when the container is for provisioning infrastructure for me.

[xmulligan]

[Ian] Best practices for a CNF can evolve over time as we learn more. It shouldn't be written in stone.

[xmulligan]

[Cristian] Maybe we should start with what a CNF does rather than what it is

[jeffsaelens]

Generic thoughts

• provides services specific to networking (Control, Management, Data - plane)
• runs in my cloud infrastructure
• provides benefits of cloud native ecosystems (self-healing, declarative deployments etc...)

[electrocucaracha]

Self-healing and auto-scaling are features offered by CNFs, declarative deployments has many advantages on the deployment process rather the functionality of CNF

[kmoha-saleem]

Scenario: Assuming VNFs and CNFs coexist: (It may happen for non-green field deployment, correct?)
In that case, Kubernetes is going to orchestrate only CNFs, and vendor-specific controllers will still be around to orchestrate their respective VNFs?
Scenario: CNFs only deployment:
In CNF’s only (no VNF's in the solution) in this case, no vendor controller is required or still, we need a vendor controller to orchestrate their CNF's?

[CsatariGergely]

Do we consider vendor provided Kubernetes Operators as a "vendor controller"?

[electrocucaracha]

AFAIU, the assumption is CNF's only scenario is the goal and projects like Virtlet and Kubevirt help on that transition

[jeffsaelens]

Discussions from the TUG/CNF principles efforts:

So what is a CNF, actually?

A CNF is network functionality delivered in software via cloud native development and delivery practices. This functionality lives within the layers of the OSI Model [9], which is used to define a network's stack. The lower layers (layers 1 and in some cases, layer 2) are provisioned for the higher layers (2-7) to provide transport. These higher layers in this instance act as applications that act upon a network payload (frames, packets datagrams etc). A physical layer 1 networking device should be "flashed" with a complete replacement of its artifacts for updates. The configuration for physical layer 1 is done with an atomic application of a versioned configuration file, which replaces the configuration on the device at once. Virtual Layer 1 (and some layer 2) is managed via templated images and bootstrapping. In contrast, layers 2 through 7 are managed by higher-level orchestration or an established control plane (an orchestrator pushing configuration versus a network protocol modifying a route table).

https://github.com/cloud-native-principles/cloud-native-principles/blob/master/cloud-native-networking-preamble.md

[CsatariGergely]

We defined the CNF term ~3 times in the last one year. We have a definition in the lost CNCF TUG WP, we have one in the CNCF TUG WP by CNCF and we have one crafted somewhat independently of CNCF TUG, but by almost the same people. I'm not sure if I'm ready to define CNF again.... I would rather select one of the already crafted definitions and refine that if needed.

[jeffsaelens]

@CsatariGergely I wasn't specific enough in my original post. I agree that at a high level, we should trust grab some of the definitions argued about in the TUG. In the charter though, it was listed that we'd define something more concrete than the executive overview definition. If the group decides that we keep things super broad, then so be it. My personal hope though is that we can spell out if OSS/BSS, infra control, orchestration (your comment above around operators shows we need clarity on certain things), etc... are considered part of the CNF or additional software.

We need to ensure that best practices provide the context to what they apply to. We don't want infra control style containers getting dinged by violating the unprivileged rule, when it very much needs to talk to the system hosting it and request resources. I apologize to all for being to vague in the original post.

[rannyh]

So, to be pragmatic, perhaps we can:

• Start with one of the "executive overviews" as sort of a straw-man for the "CNF definition".
• Use that to create the table-of-contents for the best practices as @rabi-abdel suggested in the call. Each chapter will focus on best practices that address one of the principles (e.g. Immutability, configuration, etc.).
• Start filling in the best practices in each chapter.
• Keep getting back to the "CNF definition" and refine it based on our work on the best practices.

[xmulligan]

and possibly start with an expected platform as @vukg suggested below

[taylor]

Providing context for the best practices is the main reason to have included "define CNF" as in scope. It was probably not necessary to explicitly include it.

The "CNF definition", other definitions, and frequently referred to items (eg. cloud native principles and concepts) can go into a document (maybe a glossary). That can have content that is copied or referenced else where (eg. the cloud native principles papers) or created from scratch as needed.

[xmulligan]

Example environment: k8s cluster based on upstream k8s + CNI + CSI backed by adequate persistant storage + Container Registry + Helm repository and most likely + some standard observability and logging add-ons + Git and some CICD pipeline connected to it. The CNF is free bring its own (cloud native) add-ons and install them of this platform

[vukg]

Could we structure our work around concrete CNF examples against common reference:

1. Reference is what @xmulligan referred above
2. Discuss how the CNF in subject can work in on that platform.
3. List the shortcomings and improvement measures around which we have consensus thar are in the frame of cloud native (elaborated)
4. After we exhaust all cloud native measures propose any other improvement measure keeping it as close as possible to cloud native.

we can pick 2-3 concrete CNFs and run them through these steps. After it we will have initial set of best practices.

[taylor]

Ideally every best practice proposed will list example CNFS along with use cases. It is part of the best practice definition template as required.

Gathering some example CNFs in a new discussion thread would be a good start.

[taylor]

@fkautz said in zoom chat:

https://x.CNF.dev was formational to defining the initial CNF definition which led to the creation of the CNCF TUG

[sishbi]

Also this: https://networking.cloud-native-principles.org:

A CNF is network functionality delivered in software via cloud native development and delivery practices

(This is the same as @jeffsaelens referenced above)

[xmulligan]

do we want to pull anything from x.cnf.dev into #161 cc @jeffsaelens

[jeffsaelens]

I think we could always link to the principles and x.cnf for additional info. I also think the TUG should link back to this glossary as well. So those coming to the user group can be redirected to definitions to terms that may be unclear after reading one of the white papers.