New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RA2 Ch08] Initial content for Ch08 (Gap analysis) #672
Conversation
From meeting 5/12/19
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the existing text, however I believe there is one topic missing - potentially a new chapter, or maybe an extension of 8.2.4: today in existing networks L3 VPNs are commonly used for traffic separation (e.g. separate L3 VPN for signallin, charging, LI, O&M etc.). CNFs will have to interwork with existing network elements and therefore a K8s POD will somehow need to be connected to a L3 VPN. Today this is only possible via Multus (or DANM), however typically there is a network orchestration respnsibility to connect the network interface to a gateway router (where the L3 VPN is terminated). This network orchestration is not taken care of by K8s, nor there is a production grade solution in the open source space to take care of this.
Note: with an underlying IAAS this is possible, but then it introduces (undesirable) depenency betweenworkload orchestration in K8s and infrastructure orchestration in IAAS.
Interoperability with VNF-based networking
Yes I agree, I have added this in as 8.2.7. |
@TamasZsiros if you're happy can you approve the changes please? |
<a name="8.2.4"></a> | ||
### 8.2.4 Multiple network interfaces on Pods | ||
|
||
> As well as having multiple network interfaces on Pods (e.g. Multus), being able to have different network interfaces in differnet Pods using different CNI plugins within the same cluster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also have the same features available for all network interfaces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree
- K8s as VM based VNF Orchestrator | ||
|
||
<a name="8.2.1"></a> | ||
### 8.2.1 Container run-time Interfaces towards NFVI resources |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since Container Run-time Interface (CRI) is well-defined, I think in this context we need to use a different term. Is this the OCI run-time spec?
<a name="8.2.4"></a> | ||
### 8.2.4 Multiple network interfaces on Pods | ||
|
||
> As well as having multiple network interfaces on Pods (e.g. Multus), being able to have different network interfaces in differnet Pods using different CNI plugins within the same cluster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sentence and a Typo. Suggest "As well as having multiple network interfaces on Pods (e.g. Multus), need to support different network interfaces in different Pods using different CNI plugins within the same cluster."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
@tamas, I believe this has been addressed
Approve and merge as no activity or further feedback within 2 days. |
Fixes #397
Fixes #398
Fixes #399
Fixes #400
Fixes #599
This is to look at the southbound interfaces towards the infrastructure resources.