[openstack-dev] [ovs-dev] SFC-Summary: MultiTenant

Cathy Zhang Cathy.H.Zhang at huawei.com
Tue Jul 19 19:01:53 UTC 2016


Hi Russell,

Please see inline.

Thanks,
Cathy

From: Russell Bryant [mailto:russell at ovn.org]
Sent: Tuesday, July 19, 2016 6:51 AM
To: Cathy Zhang
Cc: Farhad Sunavala; dev at openvswitch.org; Russell Bryant; Kyle Mestery
Subject: Re: [ovs-dev] SFC-Summary: MultiTenant

Even putting the multi-tenant considerations aside, I think sub-ports (tagging or encapsulation) are valuable as a mechanism to differentiate between different chains (traffic matched with different classifiers).
Cathy> Definitely. Using virtual sub-ports to differentiate different chains will greatly improve the OVS performance since this eliminates the need for re-classification at each hop. It also solves the problem caused by “some SF/VNF could change the 5-tuple or n-tuple fields of the packets that are used for chain flow classification”.  Based on info from John of Palo Alto networks, their VNF is alreadt using different virtual ports to differentiate different chains.

I agree that it's also complex that it requires coordination with the VNF - both with the vendors and a mechanism to coordinate with VNFs at runtime.

Cathy> The correlation between the sub-port and the chain needs to be communicated to the OVS as well as to the VNF. Networking-sfc’s chain API already has this info and passes this info down to the driver and OVS. The same information can be passed to VNF Manager which in turn passes to VNF. But as you said, we need coordination with the VNF manager. Different vendors could have different VNF managers. We need some agreement there.

I'd really like to understand better what people building VNFs are doing and what they want.  So many SFC conversations feel like vendors trying to guess.  I haven't actually talked to any users myself.  I just want to build what people will actually use.  :-)

Cathy> There are many different types of VNFs. Some VNFs could have a need for passing of some metadata to the next hop VNF. I would also like to hear more use cases☺

On Wed, Jul 13, 2016 at 6:18 PM, Cathy Zhang <Cathy.H.Zhang at huawei.com<mailto:Cathy.H.Zhang at huawei.com>> wrote:
Hi Russell,

To add on Farhad's point, with current neutron and nova, we cannot create a multi-tenant  VNF.
Currently, nova checks whether the neutron port belongs to the same tenant as the VM itself.
You attach a network interface (neutron port) to a VM using nova interface-attach, if the port and the VM are in different tenants, an error is given.

As to the sub-ports feature of Neutron, although it allows the sub-ports to associate with different networks, it seems these networks need to all belong to the same tenant according to vlan-aware-vms spec http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html.

It is not clear whether it can work properly if these networks belong to different tenants.
DO you know this? We may need to send an email to Neutron team for clarification on this.

Thanks,
Cathy

-----Original Message-----
From: dev [mailto:dev-bounces at openvswitch.org<mailto:dev-bounces at openvswitch.org>] On Behalf Of Farhad Sunavala
Sent: Tuesday, July 12, 2016 7:59 PM
To: dev at openvswitch.org<mailto:dev at openvswitch.org>
Subject: Re: [ovs-dev] SFC-Summary: MultiTenant

>I was thinking this could be handled with child / sub-ports.  We do
>this today for containers in VMs.  We can have a single VIF for a VM
>that is connected to multiple networks that are owned by separate
>tenants.  Some sort of encapsulation (VLAN ID, MPLS header, whatever)
>would be used to differentiate the traffic for each networking in/out
>of that VIF.  I had started adding the ability to use MPLS for this in
>my prototype for this reason, as that was what networking-sfc had defined.
I have a quick question on the above. (multi-tenancy).Yes, I know the containers can be in different networks of the same tenant.How does it work when the containers are in different tenants ?
Below is the latest spec for vlan-aware-vms https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html

The trick is to create neutron ports (for the subports) and then link them to the trunk port using neutron trunk-subport-add TRUNK \   PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \   [PORT,...]

In the above command all the neutron ports (trunk  ports and subports) must be in the same tenant.As far as I know, a tenant will not see neutron ports from another tenant.    Or will this command allow neutron ports from different tenants to be attached ?
E.g.  VM "X" consists of containers C1 in Tenant 1 with portID = C10000 (network dn1)container C2 in Tenant 2 with portID = C20000 (network dn2)The trunk port of VM "X" is in tenant 100 with portID = T10000 (network dt) The above command will be neutron trunk-subport-add T10000 \   A  vlan 10000 \   B vlan 20000 Is my understanding correct? thanks,Farhad.
_______________________________________________
dev mailing list
dev at openvswitch.org<mailto:dev at openvswitch.org>
http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev at openvswitch.org<mailto:dev at openvswitch.org>
http://openvswitch.org/mailman/listinfo/dev



--
Russell Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160719/5cf25f21/attachment.html>


More information about the OpenStack-dev mailing list