Download to read offline
![NSM vs others
CNI Multiplexers Service Meshes
• Networks are defined through
NetworkAttachmentDefinition or
ClusterNetwork/TenantNetwork resources
• Supports Static and Dynamic IP addresses
assignment.
• Creates network interfaces during the Pod Creation
• Allows to specify network interface names.
• Easy to retrieve IP addresses[1].
• Isolated networks
• Networks are defined through NetworkService
resources
• Only provides Dynamic IP addresses assignment
• Network Interfaces are created on demand
• Naming network interfaces is restricted only to
clients[2].
[2]https://github.com/networkservicemesh/networkservicemesh/blo
b/v0.2.0/sdk/endpoint/connection.go#L82-L88
[1] https://github.com/k8snetworkplumbingwg/network-attachment-
definition-client/blob/release-1.16/pkg/utils/net-attach-def.go#L63](https://image.slidesharecdn.com/buildingcloud-nativenetworkfunctions-outcomesfromthegw-testernsmimplementation-201028175942/85/Building-cloud-native-network-functions-outcomes-from-the-gw-tester-nsm-implementation-11-320.jpg)
Uploaded byVictor Morales
Building cloud native network functions - outcomes from the gw-tester nsm implementation
The document outlines the outcomes of the GW-Tester NSM implementation, detailing releases and features such as per-pod network services and interdomain support. It discusses the separation of control and user planes, multiple services per NSM endpoint, and the definition of networks through NetworkService resources. Additionally, comparisons between NSM and other CNI multiplexers are made regarding IP address assignment and network isolation.
More Related Content
![[MeetUp][2nd] 컭on턺](https://cdn.slidesharecdn.com/ss_thumbnails/2-191220021131-thumbnail.jpg?width=640&height=640&fit=bounds)
![[2015-11월 정기 세미나]K8s on openstack](https://cdn.slidesharecdn.com/ss_thumbnails/k8sonopenstack-151127132857-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
More from Victor Morales
Building cloud native network functions - outcomes from the gw-tester nsm implementation
- 2. Victor Morales v.morales@samsung.com Outcomes fromthe GW-Tester NSM implementation
- 3. NSM maps theconcept of a service mesh to L2/L3 payloads. Releases: • Aug 9, 2019 - 0.1.0 (Andromeda) Per-Pod Network Services within a single cluster support • Nov 17, 2019 - 0.2.0 (Borealis) Introduces interdomain support
- 4.
- 5. Control and UserPlane Separation https://github.com/networkservicemesh/examples/tree/master/examples/4g-network https://github.com/wmnsk/go-gtp/issues/70#issuecomment-688414207
- 6. Multiple services perone NSM endpoint https://github.com/networkservicemesh/networkservicemesh/issues/2186
- 7.
- 8. NSM Endpoint &client https://github.com/networkservicemesh/networkservicemesh/blob/v0.2.0/sdk/README.md#client-list NIC name
- 9.
- 10. Init script NICs ondemand Improvised DNS https://github.com/electrocucaracha/gw-tester/blob/master/k8s/mme_nsm.yml
- 11. NSM vs others CNIMultiplexers Service Meshes • Networks are defined through NetworkAttachmentDefinition or ClusterNetwork/TenantNetwork resources • Supports Static and Dynamic IP addresses assignment. • Creates network interfaces during the Pod Creation • Allows to specify network interface names. • Easy to retrieve IP addresses[1]. • Isolated networks • Networks are defined through NetworkService resources • Only provides Dynamic IP addresses assignment • Network Interfaces are created on demand • Naming network interfaces is restricted only to clients[2]. [2]https://github.com/networkservicemesh/networkservicemesh/blo b/v0.2.0/sdk/endpoint/connection.go#L82-L88 [1] https://github.com/k8snetworkplumbingwg/network-attachment- definition-client/blob/release-1.16/pkg/utils/net-attach-def.go#L63
- 12.
Editor's Notes
- #3 Short Description: Deep dive session for sharing lessons learned during the testing and Network Service Mesh (NSM) implementation in the GW-Tester project. Detailed Description: The GW-Tester project is a set of tools created for testing GPRS Tunneling protocols. During the last Virtual Event, the journey to transform the GW-Tester to a Cloud-Native architecture was presented. In that session, we discussed some considerations from the Container's design to the CNI multiplexer implementation details. This session covers lessons learned and discovered during the Network Service Mesh (NSM) implementation. NSM offers a different approach compared to Multus and DANM to manage multiple network interfaces and this may result in Architectural changes on the CNF. The audience will get familiar with some considerations to take at the moment to consume NSM SDK. People from the ONAP, OPNFV and CNTT communities might find this information relevant to their projects.