[ovs-dev] SFC-Summary: MultiTenant

Kyle Mestery mestery at mestery.com
Wed Jul 13 15:12:16 UTC 2016


On Tue, Jul 12, 2016 at 6:57 PM, Cathy Zhang <Cathy.H.Zhang at huawei.com> wrote:
> Hi Kyle/Russell,
>
> -----Original Message-----
> From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Kyle Mestery
> Sent: Tuesday, July 12, 2016 9:19 AM
> To: Russell Bryant
> Cc: dev at openvswitch.org; John McDowall
> Subject: Re: [ovs-dev] SFC-Summary: MultiTenant
>
> On Tue, Jul 12, 2016 at 9:52 AM, Russell Bryant <russell at ovn.org> wrote:
>> On Tue, Jun 28, 2016 at 12:05 PM, Ryan Moats <rmoats at us.ibm.com> wrote:
>>
>>> John McDowall <jmcdowall at paloaltonetworks.com> wrote on 06/28/2016
>>> 10:54:31
>>> AM:
>>>
>>> > From: John McDowall <jmcdowall at paloaltonetworks.com>
>>> > To: Ryan Moats/Omaha/IBM at IBMUS, Na Zhu <nazhu at cn.ibm.com>
>>> > Cc: "dev at openvswitch.org" <dev at openvswitch.org>
>>> > Date: 06/28/2016 10:54 AM
>>> > Subject: Re: [ovs-dev] SFC-Summary: MultiTenant
>>> >
>>> > Ryan,
>>> >
>>> > Putting on my vendor hat for a minute or two….
>>> >
>>> > The way we have solved this is our VNF supports multiple interfaces
>>> > (I.e. Multiple port-pairs) that can be partitioned into different
>>> > networks. So a single VNF can act in multiple tenant. I believe
>>> > most other vendors have similar solutions and perhaps other approaches.
>>>
>>> That's a way to do it, and it doesn't require OVN to know any more
>>> than what we are currently programming...
>>>
>>> >
>>> > How would you like a VNF to behave to support multi-tenancy?
>>>
>>> I've been trying to work out how to be multi-tenant at the VNF port
>>> level, and there's where I run into problems...
>>>
>>
>> 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.
>>
>
> This makes the assumption that the thing on the other end of the port (the VNF, I guess) is not only MPLS aware, but also "tenant to label"
> aware. How does that information (tenant to MPLS label) get passed to the VNF? Apologies if this is already handled somehow with the networking-sfc API.
>
> Cathy> From networking-sfc point of view, there is no need for the VNF to be MPLS or VLAN aware. A key point of using MPLS or "NSH in the future" is to simplify the OVS's SFC forwarding table, i.e. instead of forwarding based on the n-tuple of the packet, the OVS can forward the packet to the next VNF based on a simple "chain-ID" carried in the MPLS or NSH. But once the OVS figures out the egress port for the packet, the OVS can either forward the packet with the "chain-ID" if the VNF is MPLS/NSH aware or strips off the MPLS/NSH header from the packet and then forward it to the VNF if the VNF is the MPLS/NSH unaware.
>
> Cathy> Let's assume that this sub-port mechanism can be used to support multi-tenancy (we still need to test whether a VM created by Nova can support multi-tenancy or not since according to Nova API, a VM is only associated with one tenant). If the VNF will provide the same treatment for different tenants, then there is no need for the VNF to be tenant aware. But if the VNF needs to provide different treatment for different tenants, then VNF needs to be tenant aware or "tenant to label" aware as Kyle said. One way to support this latter case is to make the VNF be MPLS/NSH aware. That is, the chain-ID label can uniquely identify the tenant since each chain ID is associated with one tenant.
>

The "service VM / container" concept has been around since LBaaS V2
days, I recall pushing some code in 2014 to allow this by creating an
"advsvc" user, which would allow for an admin user to create entities
on behalf of tenants. Something similar may exist for nova, though I'm
not sure.

Your comment above about making the VNF chain-ID aware means some sort
of orchestration needs to happen to pass "tenant to chain-ID"
information to the VNF though, which isn't there today based on this
thread. networking-sfc assumes chains and VNFs are per-tenant today,
and not multi-tenant, is what I've gotten out of this thread.

[1] https://github.com/openstack/neutron/blob/master/etc/policy.json

> Thanks,
> Cathy
>
>
>> --
>> Russell Bryant
>> _______________________________________________
>> dev mailing list
>> dev at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev



More information about the dev mailing list