How about physical_network in TOSCA for SR-IOV
Problem Description:
In a nutshell, How can we provide the physical_netwrok information (which is required by OpenStack when to use SR-IOV) in TOSCA VNFD?
In OpenStack, when to use SR-IOV, physical_network is needed both by the administrator and the users.
First the administrator need to do some configurations for SR-IOV for various openstack services, e.g.
nova configurations (i.e. nova.conf):
pci_passthrough_whitelist={"address":"0000:08:00.0", "physical_network":"physnetNFV"}
scheduler_default_filters = <defaultlist>, PciPassthroughFilter
neutron ml2 configurations: (ml2.conf)
[ml2_sriov]
supported_pci_vendor_devs = 8086:10fb
agent_required = False
[sriov_nic]
physical_device_mappings = physnetNFV:eth1
To use SR-IOV, users first need to create a network using the appropriate physical_network according the the administrator's configuration, then create a port and launch a VM by that port, e.g.
openstack network create --provider-network-type flat --provider-physical-network physnetNFV sriov-net
... ...
openstack port create --vnic-type direct --network sriov-net ... sriov-port
openstack server create ... ... --nic --port-id=<uuid of port sriov-port created above> ...
In Heat, we could provide the physical_network information in the template as:
sriov_net:
type: OS::Neutron::Net
properties:
name: sriov_network
network_type: flat
physical_network: physnetNFV
/** Subnet details are not provided for brevity**/
sriov_port:
type: OS::Neutron::Port
properties:
name: sriov_port
network_id : { get_resource: sriov_network}
binding:vnic_type: direct
virtual_firewall_appliance:
type: OS::Nova::Server
image: ....
networks:
- port: {get_resource: sriov_port}Now the question is how about the TOSCA VNFD.
Proposals:
Here we came up with 3 proposals about how to provide such physical_netwrok information in tosca VNFD.
1. Using physicalNetwork property specific in ONAP R2 DM
In ONAP R2 DM, we have the physicalNetwork property in virtual link profile data type, and we can use that.
VL_mux_gw_private_net:
type: tosca.nodes.nfv.VnfVirtualLink
properties:
connectivity_type:
layer_protocol: ipv4
vl_profile:
... ...
networkName: sriov_net
cidr: ......
dhcpEnabled: false
physicalNetwork: physnetNFVPros:
no need to change the tosca work flow within ONAP for policy/oof
Cons:
VNF provider should NOT know the underlying cloud configuration information, such as physical_network information(Yes, heat template has the same problem), before they create their own VNFD.
The physicalNetwork property above is not in IFA011 or SOL001, so it might be removed in the future.
SR-IOV requirement is specified as HPA features in CP node in tosca VNFD, ONAP policy generator needs to back reference from CP to corresponding VL to get the relevant information.
2. Put the information in SRIOV specific HPA feature
Since physical_network information is for SR-IOV only in our case, we could add this information into the HPA feature's configurationValue, in the format of <interface_type>:<physical_network>
Cp_SRIOV:
type: tosca.nodes.nfv.VduCp
properties:
... ...
virtual_network_interface_requirements:
- name: sriov
support_mandatory: true
network_interface_requirements:
interfaceType: '{"schemaVersion": "0","schemaSelector": "","hardwarePlatform": "generic","mandatory": "true", "configurationValue": "SR-IOV:physnetNFV"}'
nic_io_requirements:
pciVendorId: '{"schemaVersion": "0","schemaSelector": "","hardwarePlatform": "generic","mandatory": "true", "configurationValue": "8086"}'
pciDeviceId: '{"schemaVersion": "0","schemaSelector": "","hardwarePlatform": "generic","mandatory": "true", "configurationValue": "10fb"}'Pros:
no need to change the tosca work flow within ONAP for policy/oof
No inconsistency to IFA011 or SOL001.
policy generator can just parse the VNFD Cp definition and generate the corresponding rules for OOF.
Cons:
VNF provider should NOT know the underlying cloud configuration information, such as physical_network information(Yes, heat template has the same problem), before they create their own VNFD.
3. Put the information as a runtime property/input in HPA feature
Ideally, the VNF provider should NOT know the underlying cloud configuration information when he/she create the onboarding VNFD. So we can put the physical_network information as a runtime property/input by using tosca function.
inputs:
sriov_physical_net :
type: string
description: physical network for sriov
......
node_templates:
Cp_SRIOV:
type: tosca.nodes.nfv.VduCp
properties:
... ...
virtual_network_interface_requirements:
- name: sriov
support_mandatory: true
network_interface_requirements:
interfaceType: { concat : [ '{"schemaVersion": "0","schemaSelector": "","hardwarePlatform": "generic","mandatory": "true", "configurationValue": ',
'"SR-IOV:', { get_input: sriov_physical_net }, '"}'
]
nic_io_requirements:
pciVendorId: '{"schemaVersion": "0","schemaSelector": "","hardwarePlatform": "generic","mandatory": "true", "configurationValue": "8086"}'
pciDeviceId: '{"schemaVersion": "0","schemaSelector": "","hardwarePlatform": "generic","mandatory": "true", "configurationValue": "10fb"}'
Pros:
VNF provider doesn't need to know the underlying cloud configuration information
No inconsistency to IFA011 or SOL001.
Cons:
Need to change the ONAP internal work flow. Policy can not generate the corresponding policy rules for OOF until SDNC has finished its operations and provide the tosca input, or unless the service designer can provide the default value of the input parameter.
I don't believe we have time to finish this in C release.
Comments
Which should provide the physical_network information to OOF? If the physical network information is only for oof-vfc-multicloud, then I think there is no need to include any place holder parameter at all in the onboarding VNFD.
The reason we brought up SDNC is that SDNC was used to create the network resources and fill up the parameters in heat template, so we assume it would play the same part for our tosca parameters too.
@Haibin Huang (Deactivated) @Ruoyu Ying (Deactivated) Please check the questions above.
Policy with physical network information is created dynamically by Policy framework based on information in TOSCA VNFD. So, requirements wise we expect VNFD (not VNF vendor given, but modified by deployer) within TOSCA or in the environment) to provide enough information to create the policy. In case of HOT, policy created manually and hence no issues.
Essentially,
Vendor given VNFD will have get_input() for physical networks.
Operator that onboards the VNFD will populate the input parameters (whatever the scheme is. In case of HOT, it is called environment file. I don't know what is called in TOSCA) with right physical network information.
As part of on-boarding, policy framework creates the policy with the right information as Dm-to-policy translator has enough information from the VNFD and corresponding input values.
During instantiation, OOF returns the OOF_directives. Based on OOF_directices parameters, appropriate values filled up by VF-C while talking Openstack or VNFMs (as VFC doing today).
I thought SRIOV configuration in the NIC required inventory assignment of "vf"s on the nic not just policy. but in any case the instance specific parameters will either require assignment from SDNC or configuration of the device post instantiation form SDNC/APPC/VFC/Legacy. Instance specific parameters are in some cases required at vm/container instantiation since they are not part of the model from the vendor but implement service provider rules that might look like service + vnf_model + vnf_vendor + location + sequence_number to fit into legacy network operations.
VNF provider should not be knowing the physical network information. Even in HEAT, it is proposed to put as a parameter. That parameter is filled up by Multi-Cloud at run time based on information in oof_directives. Keeping that in mind, I also feel that Option 3 is closest and preferable.
I don't understand the Cons for Option 3. What is the dependency with the SDNC? In my view, VF-C has to talk to OOF to get the oof_directives where physical network name is provided and same is expected to be provided to Multi-Cloud.
Srini