[RA2] Networking solution changes

[tomkivlin]

As per multiple discussions on the topic, I propose a change whereby the architectural components / building blocks are described in chapter 3, and this is where I think the comparison table best sits. Then the specifications in chapter 4 are cleaner and more discrete.

Resolves #2119

[pgoyal01]

@tomkivlin Why have a comparison table? It is limited only to 2 out of many available solutions.

[tomkivlin]

@tomkivlin Why have a comparison table? It is limited only to 2 out of many available solutions.

I think it's worth showing the different approaches that can be taken. Happy to add words to that effect.

[rgstori]

approved

[pgoyal01]

@tomkivlin Does the chapter need the types of networking -- host, overlay, underlay , ...? Depending upon the type of networking chosen would determine the CNIs.

[tomkivlin]

@tomkivlin Does the chapter need the types of networking -- host, overlay, underlay , ...? Depending upon the type of networking chosen would determine the CNIs.

Perhaps - I'm keen to avoid repeating Kubernetes documentation for the sake of it, so if we can link it back to the requirements then yes.

[tomkivlin]

@fkautz I don't know enough about NSM to know whether the specs as presented in chapter04.md prevent its use? e.g. one that concerns me is ra2.ntw.003 as I'm not sure whether NSM uses the CNI to integrate with the k8s control plane - my understanding is that it uses Device Plugin API and the kube-apiserver - is that right?

[tomkivlin]

@pgoyal01 @fkautz @cntt-n/ref-a2 we need just one more approval on this monster please. Many thanks for inputs so far!

@tomkivlin I will approve but please see a comment w.r.t. "ra2.k8s.011 Anuket Profile Labels" below.

[pgoyal01]

Approved but there is one suggestion about a reference