Cni - Revision history

Martindenico: activeActiveL3 changed to activePassiveL3 as per approved contribution NFVSOL(22)000333

2022-07-07T14:40:04Z

activeActiveL3 changed to activePassiveL3 as per approved contribution NFVSOL(22)000333

← Older revision		Revision as of 15:40, 7 July 2022
Line 139:		Line 139:
	"type": "string",		"type": "string",

	"enum": [ "infraProvided", "left", "right", "activeActiveBond", "activePassiveBond", "~~activeActiveL3~~" ],		"enum": [ "infraProvided", "left", "right", "activeActiveBond", "activePassiveBond", "activePassiveL3" ],

	"description": " Switchplane redundancy management method "		"description": " Switchplane redundancy management method "
Line 314:		Line 314:
	\|The interfaces are bonded in active-passive mode in the application with move of bond MAC address. No specific requirements on DC fabric. Typically corresponds to bonding mode-1 “active-backup”		\|The interfaces are bonded in active-passive mode in the application with move of bond MAC address. No specific requirements on DC fabric. Typically corresponds to bonding mode-1 “active-backup”
	\|-		\|-
	\|~~activeActivel3~~		\|activePassiveL3
	\|Application moves its IP address by attaching it to one of the two MACs by use of GARP messages.		\|Application moves its IP address by attaching it to one of the two MACs by use of GARP messages.
	\|}		\|}

Martindenico: /* 2 JSON schema */ comma after last item in properties in line 75 deleted

2022-05-31T14:21:28Z

2 JSON schema: comma after last item in properties in line 75 deleted

← Older revision		Revision as of 15:21, 31 May 2022
Line 107:		Line 107:
	"description": "List of speeds in bps the driver is verified to work with in a direct.userspace, direct.kernel or bond interface. If nicType is present, the speeds are applicable to that nicType."		"description": "List of speeds in bps the driver is verified to work with in a direct.userspace, direct.kernel or bond interface. If nicType is present, the speeds are applicable to that nicType."

	},		}

	},		},

Martindenico: /* 2 JSON schema */

2022-05-31T07:44:29Z

2 JSON schema

← Older revision		Revision as of 08:44, 31 May 2022
Line 252:		Line 252:

	]		]

	}		}
	\|}		\|}
Line 363:		Line 364:
	{\| class="wikitable"		{\| class="wikitable"
	\|		\|

	network_interface_requirements:		network_interface_requirements:

Line 381:		Line 381:
	{\| class="wikitable"		{\| class="wikitable"
	\|		\|

	network_interface_requirements:		network_interface_requirements:

Line 400:		Line 399:
	{\| class="wikitable"		{\| class="wikitable"
	\|		\|

	network_interface_requirements:		network_interface_requirements:

Line 418:		Line 416:
	{\| class="wikitable"		{\| class="wikitable"
	\|		\|

	network_interface_requirements:		network_interface_requirements:

Line 438:		Line 435:
	{\| class="wikitable"		{\| class="wikitable"
	\|		\|

	network_interface_requirements:		network_interface_requirements:

Line 456:		Line 452:
	{\| class="wikitable"		{\| class="wikitable"
	\|		\|

	network_interface_requirements:		network_interface_requirements:

Line 474:		Line 469:
	{\| class="wikitable"		{\| class="wikitable"
	\|		\|

	network_interface_requirements:		network_interface_requirements:

Martindenico at 07:40, 31 May 2022

2022-05-31T07:40:50Z

← Older revision		Revision as of 08:40, 31 May 2022
Line 1:		Line 1:
			[[https://nfvwiki.etsi.org/index.php?title=NFVI_Platform_Capability_Registry back to NFVI Platform Capability registry]]

	== '''1 Registration information''' ==		== '''1 Registration information''' ==

Martindenico: /* 4 Examples of requirements on the cni capability for SOL001 */

2022-05-31T07:33:37Z

4 Examples of requirements on the cni capability for SOL001

← Older revision		Revision as of 08:33, 31 May 2022
Line 356:		Line 356:

	== '''4 Examples of requirements on the cni capability for SOL001''' ==		== '''4 Examples of requirements on the cni capability for SOL001''' ==
			1. The following example shows the expression of a requirement for this capability for an interface of type kernel.netdev. The requirement can be fulfilled e.g. with the OVS CNI<sup>TM</sup> and vSwitch redundancy. One single NAD is required.

			Note: it is not necessary to indicate the interfaceRedundancy for this interfaceType.
			{\| class="wikitable"
			\|

			network_interface_requirements:

			cni: \|

			version: 1.0

			mandatory: true

			configuration_value:

			interfaceType: kernel.netdev

			interfaceRedundancy: infraProvided
			\|}
			2. The following example shows the expression of a requirement for this capability for an interface of type direct.kernel and interface redundancy ActivePassiveBond. The requirement can be fulfilled with the SRIOV CNI<sup>TM</sup> for a cluster on bare metal or with a HOST-DEVICE CNI<sup>TM</sup> for a VM based cluster. The redundancy is based on a mated pair of vNICs provided by the infrastructure one connected to the left switch plane, the other to the right switch plane. Thus, two NADs are required.
			{\| class="wikitable"
			\|

			network_interface_requirements:

			cni: \|

			version: 1.0

			mandatory: true

			configuration_value:

			interfaceType: direct.kernel

			interfaceRedundancy: ActivePassiveBond
			\|}

			3. The following example shows the expression of a requirement for this capability for an interface of type direct.kernel and interface redundancy infraProvided. The requirement can be fulfilled with the SRIOV CNI<sup>TM</sup> for a cluster on bare metal or with a HOST-DEVICE CNI<sup>TM</sup> for a VM based cluster. There is a single vNIC and the redundancy is based on a physical NIC connected to both switchplanes and providing the bonding (a.k.a. smartNIC). One single NAD is required.
			{\| class="wikitable"
			\|

			network_interface_requirements:

			cni: \|

			version: 1.0

			mandatory: true

			configuration_value:

			interfaceType: direct.kernel

			interfaceRedundancy: infraProvided
			\|}
			4. The following example shows the expression of a requirement for this capability for an interface of type bond and interface redundancy ActivePassiveBond. This is also a direct mode that provides direct access to the network PCI. The requirement is fulfilled with the BOND CNI<sup>TM</sup>. The redundancy is based on a mated pair of vNICs provided by the infrastructure one connected to the left switch plane, the other to the right switch plane and the BOND CNI<sup>TM</sup> provides the bonding in userspace. Thus, three NADs are required.
			{\| class="wikitable"
			\|

			network_interface_requirements:

			cni: \|

			version: 1.0

			mandatory: true

			configuration_value:

			interfaceType: bond

			interfaceRedundancy: ActivePassiveBond
			\|}
			5. The following example shows the expression of a requirement for this capability for two independent interfaces of type direct.kernel. The application manages the redundancy with support of routing protocols. The requirement can be fulfilled with the SRIOV CNI<sup>TM</sup> for a cluster on bare metal or with a HOST-DEVICE CNI<sup>TM</sup> for a VM based cluster. One NADs is required in each of the VduCps.

			In VduCpd (left):
			{\| class="wikitable"
			\|

			network_interface_requirements:

			cni: \|

			version: 1.0

			mandatory: true

			configuration_value:

			interfaceType: direct.kernel

			interfaceRedundancy: left
			\|}
			In VduCpd (right):
			{\| class="wikitable"
			\|

			network_interface_requirements:

			cni: \|

			version: 1.0

			mandatory: true

			configuration_value:

			interfaceType: direct.kernel

			interfaceRedundancy: right
			\|}
			6. The following example shows the expression of a requirement for this capability for an interface of type direct.userspace and interface redundancy ActivePassiveBond. The requirement can be fulfilled with the SRIOV CNI<sup>TM</sup> for a cluster on bare metal or with a HOST-DEVICE CNI<sup>TM</sup> for a VM based cluster. The redundancy is based on a mated pair of vNICs provided by the infrastructure one connected to the left switch plane, the other to the right switch plane. Thus, two NADs are required. The application has been verified to work with the i710 NIC and 1 Gbps and 10 Gbps.
			{\| class="wikitable"
			\|

			network_interface_requirements:

			cni: \|

			version: 1.0

			mandatory: true

			configuration_value:

			interfaceType: direct.kernel

			interfaceRedundancy: ActivePassiveBond

			nicOptions:

			- nicType: i710

			speeds: [ 1000000000, 10000000000 ]
			\|}

Martindenico at 07:29, 31 May 2022

2022-05-31T07:29:49Z

← Older revision		Revision as of 08:29, 31 May 2022
Line 354:		Line 354:

	An invalid use of nicOptions or interfaceOptions can be ignored.		An invalid use of nicOptions or interfaceOptions can be ignored.

			== '''4 Examples of requirements on the cni capability for SOL001''' ==

Martindenico at 07:28, 31 May 2022

2022-05-31T07:28:53Z

← Older revision		Revision as of 08:28, 31 May 2022
Line 288:		Line 288:
	\|NVIDIA<sup>®</sup> Mellanox<sup>®</sup> ConnectX<sup>®</sup>-6 adapters product family.		\|NVIDIA<sup>®</sup> Mellanox<sup>®</sup> ConnectX<sup>®</sup>-6 adapters product family.
	\|}		\|}
			The interfaceRedundancy can take one of the following values:

			{\| class="wikitable"
			\|+
			\|infraProvided
			\|The application sees one vNIC but the infrastructure provides redundant access to the network via both switch planes. For interface of type kernel.netdev the redundancy is provided by the vSwitch or Linux bonding. For interfaces of type direct, it requires that the physical NIC is connected to both switch planes (a.k.a. smartNIC). Thus it imposes hardware requirements on the infrastructure. For interface of type userspace redundancy handled by a DPDK-OVS or VPP vSwitch
			\|-
			\|left
			\|A vNIC connected non-redundantly to the network via one specific (left) switchplane. Valid for interfaces of type direct.userdrive or direct.kernel. Redundancy is implemented by having two connection points, indicating different values (left/right) in the descriptor.
			\|-
			\|right
			\|A vNIC connected non-redundantly to the network via one specific (right) switchplane. Valid for interfaces of type direct.userdrive or direct.kernel. Redundancy is implemented by having two connection points, indicating different values (left/right) in the descriptor.

			NOTE: left and right switch planes are logical terms that refer to physically disjoint switching resources. They can for example be implemented as two independent sets of ethernet switches or a set of switches connected so that no single switch failure would cause end to end connectivity over the switching infrastructure to fail.
			\|-
			\| colspan="2" \|For the following cases the infrastructure provides for the single VduCp a mated pair of vNICs connected to the same network, one via left switchplane, the other via the right switchplane:
			\|-
			\|activeActiveBond
			\|Requires a static multi-chassis LAG in active-active mode from the infrastructure. Typically corresponds to bonding mode-2 “balance-xor”
			\|-
			\|activePassiveBond
			\|The interfaces are bonded in active-passive mode in the application with move of bond MAC address. No specific requirements on DC fabric. Typically corresponds to bonding mode-1 “active-backup”
			\|-
			\|activeActivel3
			\|Application moves its IP address by attaching it to one of the two MACs by use of GARP messages.
			\|}
			The valid combinations of values for the interfaceType and the interfaceRedundancy properties as well the applicability of the nicOptions and interfaceOptions are shown in the following table:
			{\| class="wikitable"
			\|+
			!'''interfaceType'''
			!'''nicOptions'''
			!'''interfaceOptions'''
			!'''interfaceRedundancy'''
			\|-
			\|kernel.netdev
			\|Not applicable
			\|Not applicable
			\|infraProvided
			(default, no need to indicate)
			\|-
			\|direct.userspace
			\|Applicable
			\|Not applicable
			\|left, right, activeActiveBond, activePassiveBond, activePassiveL3, infraProvided
			\|-
			\|direct.kernel
			\|Applicable
			(only speeds)
			\|Not applicable
			\|left, right, activeActiveBond, activePassiveBond, activePassiveL3, infraProvided
			\|-
			\|bond
			\|Applicable
			(only speeds)
			\|Not applicable
			\|activeActiveBond, activePassiveBond
			\|-
			\|userspace
			\|Not applicable
			\|Applicable
			\|InfraProvided
			(default, no need to indicate)
			\|}
			An invalid combination of interfaceType and interfaceRedundancy shall be rejected.

			An invalid use of nicOptions or interfaceOptions can be ignored.

Martindenico: /* 3 Detailed description */

2022-05-31T07:17:02Z

3 Detailed description

@@ Line 23: / Line 23: @@
 |-
 |Description
-|This capability represents the realization of a secondary container cluster network interface.
+|This capability represents the realization of a secondary container cluster network interface. The expression of the related requirements allows the selection of a suitable CNI<sup>TM</sup> and configuration of the Network Attachment Definition (NAD) or NADs accordingly.
 |}
@@ Line 258: / Line 254: @@
 == '''3 Detailed description''' ==

Martindenico at 07:03, 31 May 2022

2022-05-31T07:03:02Z

← Older revision		Revision as of 08:03, 31 May 2022
Line 256:		Line 256:
	}		}
	\|}		\|}

			== '''3 Detailed description''' ==

Martindenico at 07:01, 31 May 2022

2022-05-31T07:01:13Z

Show changes