Thanks for your additional precisions.
If I understand you correctly:
- both huaweicloud.com and huawei powered clouds such as Orange Flexible Engines (or others such as DeutchTelecom cloud and Telefonica Cloud, powered by Huawei FusionSphere  ...) implement the subset of the openstack APIs required by the openstack CPI. Users of these clouds can use the openstack cpi and have to provision the prerequisite openstack objects as documented into , which include network, subnet, router, router_interface objects (which can be automatically provisioned using terraform using templates shared in ). - in addition, huaweicloud.com (and FusionSphere ?) supports a simplified networking model which include the VPC  and subnet concepts 
The huaweicloud cpi mostly uses the native openstack APIs in huaweicloud, except for networking where it uses the huawei specific simplified networking model: this brings the benefit of a simplier CPI configuration for operators, especially the ones familiar with the huaweicloud console: it makes them easier to map concepts visible in the console to cpi configuration fields. I understand The huaweicloud cpi does not currently bring any other features for bosh w.r.t. the openstack cpi.
If my understanding is correct, then it might make sense to instead contribute documentation refinements to the openstack cpi  and  as to guide huaweicloud console users into steps to configure the openstack CPI (such as step by step guide to provision and configure the associated VPC, possibly illustrated with terraform configs).
My team at Orange went through the mapping huaweicloud console concepts to openstack ones in order to configure the terraform provider and bosh-director cloud-config, and indeed felt clarifying documentation would help.
Besides, I wonder if Huawei team is considering the following other contributions which I believe will bring great benefits to the Huawei customers and the overall community, in summary "bring Huawei cloud 1st class support in bosh and cloudfoundry":
1- validate the full openstack cpi coverage on huawei cloud, including latest features such as LBaaS support, or other vm-extensions. This may make sense to contribute computing and engineering resources to the Bosh stack cpi team and add Huawei cloud to the CF Foundation CI pipelines, see related 
1b- extend the openstack cpi with additional vm_properties support that leverage Huawei custom APIs and products. It would be great to see work with the openstack CPI team to design support for openstack extensions in the openstack CPI in a similar fashion as the openstack validator custom extensions, that would avoid a complete fork of the openstack cpi.
2- build a community of huawei cloud Bosh and CF users which can share experience, best practices, and provide feedback and improvements to the Huawei and CF Foundation teams. For example, create a "huawei" slack channel on the cloudfoundry slack . Our team would be happy to share our experiences with running CF on Orange Flexible Engine, such as glance quota diagnostics , or VRRP issues across VPCs .
3- provide 1st class support to Huawei cloud on bosh director, e.g. validate integration of Huawei Object Store Service  as a bosh director blobstore backend, and BBR backend . Contribute docs and operators into bosh-deployment similarly to other Iaas , , as well as terraform configs into bbl . Validate integration of Huawei RDS as a bosh director db backend . We should suggest to avoid fragmentation of terraform providers among huawei powered clouds     and their associated diverging github repos  , and rather try to unify them into a single provider with configureable endpoint.
4- provide 1st class support to Huawei cloud on cloudfoundry application runtime, e.g. validate integration of Huawei Object Store Service  as a CC blobstore backend and contribute associated bosh operators into cf-deployment  or best in bbl, along with terraform configs (when differing from openstack apis)
I look forward to learning more about Huawei plans to bring 1st class support to bosh and cloudfoundry.
Thanks in advance for Huawei contribs to the Cf community, and for reading through this way too long email :-)
Add a little additional description. The original OpenStack network model is network, subnet, and router. The simplified network simplified model is vpc, subnet in Huawei Public Cloud console.
so we add the new property named 'subnet_id', and the Port is not required in Huawei Public Cloud network API.
Is this clear to you?