[RA2 Ch2] - review CNI and other networking requirements

[jeffsaelens]

Question, why is a CNI multiplexer being made a hard requirement as opposed to just setting a requirement to support multiple network interfaces?

"Because req.inf.ntw.01 requires the architecture to support CNI and req.inf.ntw.16 requires the capability to attach several network interfaces to the pods the architecture must support a CNI metaplugin/CNI multiplexer."

[nickolaev]

I would propose a slightly different approach, instead of specifying CNI as an interface to a network provisioning facilities for the pods, talk about the properties that are needed. CNI is something that evolves and we don't have control over what is going to happen next year. What if we suddenly get to CNI 0.8, where a pod does not get an interface but a set of pre-allocated TCP sockets to the nearest side-car proxy instead. Remember, that's more or less what these apps need today (that is why Istio and friends are so popular). Then you will have to "pin" versions of the CNI for example.

Instead, we may talk about the needs of specific traits of the solution:

• the need for "raw" L2 interfaces
• access to network HW
• Multiple interfaces
  and so on. Yes, today these might be satisfied with ceratin combinations of CNI plugins, but that better suit the Reference Implementation, not the Reference Architecture, IMO.

[nickolaev]

@jeffsaelens I believe the title needs to be renamed to include RA2 and may be references to the specific chapter.

[CsatariGergely]

CNTT follows an approach to start with the requirements (similar to what @nickolaev wrote) which are defined in the Reference Model (and cross referenced in Chapter 2.2), from these requirements we build a high level architecture based on the existing capabilities of open source components in Chapter 3 which is turned into a component level design in Chapter 4.

At the moment there is no other production grade solution to provide several interfaces to a container than using DANM or Multus, a CNI multiplexer.

[ulikleber]

Even if we know of only one solution, we should not require the solution, but specify the real requirement.

[jeffsaelens]

Even if we know of only one solution, we should not require the solution, but specify the real requirement.

This captures my intent for opening this issue. Architecture and Requirements are not the same thing. One feeds the other. The wording should be phrased in a way that distinction is clear.

It sounds like the requirements are around multi-interface solutions and packet treatment. A reference architecture that might meet this requirement would be CNI-Multiplexing.

[tomkivlin]

@jeffsaelens @nickolaev @ulikleber I've renamed this issue to reflect what needs to happen (as per @nickolaev's comment).

I think a PR that modifies the networking requirements in chapter 2 is what we need, which will then allow us to flow through into subsequent chapters. I would start with @nickolaev's suggestions.

[CsatariGergely]

Let's not forget, that CNTT is about making selections and limiting options. In RA2 we need to select components which are visible for the VNF which includes the CNI-s and the CNI multiplexer.
What @nickolaev suggests here is what we have in the RM, but in the RA we need to be more specific.

[tomkivlin]

@CsatariGergely that's fine, I think all we're saying is the requirement shouldn't be to specify solutions - as per #1184 I'm OK for now for RA2 specifying components, but the requirements and arch spec need to back that up rather than the choice (e.g. CNI in this example) being the starting point.

[CsatariGergely]

Okay, I was a bit list and did not check the target chapter of this. According to the current state:

• Chapter 2 does not set hard requirement for a CNI multiplexer. It sets requirement for CNI in req.inf.ntw.01 and inherits the requirement for multiple interfaces.
• Chapter 3 requires CNI muliplexer based on req.inf.ntw.01 and req.inf.ntw.16 what I believe the best and maybe the only option to support both CNI and multiple interfaces. This chapter is an "L2 CNTT artefact", so its purpose to specify solutions.

Is this issue is about to remove the CNI requirement from Chapter 2 of RA2, about to remove the multiple interfaces requirement from RM or about to remove the CNI multiplexer requirement from Ch 3?

[jnummelin]

Is this issue is about to remove the CNI requirement from Chapter 2 of RA2, about to remove the multiple interfaces requirement from RM or about to remove the CNI multiplexer requirement from Ch 3?

Maybe a slight re-wording would suffice here in ch3:

the architecture must support a CNI metaplugin/CNI multiplexer.

-->

the architecture should support a CNI metaplugin/CNI multiplexer or some other CNI compliant way to attach multiple interfaces to a pod.

So basically this would capture the general requirement of being CNI compliant (at least on one of the pod nw interfaces) but still allow some other means to attach "secondary" interfaces to a pod if such way is some day available.

[tomkivlin]

CNI specifics are visible in pod manifest. Ch4 needs to specify CNI/network solution/service mesh/etc. products/solutions to be used to conform to RA2.
Different networking requirements for multiple networking functions.
e.g. NFs that require SCTP.
Suggestion from @ramkri123:

1. List networking requirement for 5G core functions (next level down from VNF analysis in RM Chapter 2)
2. Update RA2 chapter 2
3. Update chapters3 and 4 accordingly.

[jeffsaelens]

@jnummelin is capturing my concerns. The wording is a little too nebulous for me as architecture and requirements are being treated interchangeably. It sounds like the requirements are for CNI compliance and multiple interfaces. The architecture being proposed in RA2 is to meet these requirements via a CNI multiplexer.

A clear delineation of of requirements vs proposed architecture across the chapters would clean a lot of the confusion I had up when I first opened this issue.

[ASawwaf]

@tomkivlin , I hope this req. be defined in Networking Focus Group

[tomkivlin]

Can I suggest the following overall approach - I am happy to go back over the chapters to ensure we follow this principle if all agree with it:

Ch02 - document requirements, avoid those that define a specific choice
Ch03 - describe functional capabilities and interfaces - maybe with examples such as CNI/NSM but avoid if possible
Ch04 - articulate the specifications - i.e. the specific choices and configurations that deliver the capabilities/interfaces (ch03) and the requirements (ch02)

Which should mean CNI is removed from ch02, the networking model is described in ch03 and then the specific interfaces (CNI, eBPF, etc.) and networking solutions (Calico, DANM, Multus, NSM) can be described in ch04. This may also mean ch05 is not required as the interface specs are all in ch04.

[CsatariGergely]

Which should mean CNI is removed from ch02, the networking model is described in ch03 and then the specific interfaces (CNI, eBPF, etc.) and networking solutions (Calico, DANM, Multus, NSM) can be described in ch04. This may also mean ch05 is not required as the interface specs are all in ch04.

RM2 meeting on 2020.03.19 agreed to implement the approach in the frame of #1338

[jeffsaelens]

@tomkivlin this approach looks a lot cleaner.

[tomkivlin]

@tomkivlin to link PR that will fix #1338 to this issue also.