On Tue, Jul 12, 2016 at 6:57 PM, Cathy Zhang <cathy.h.zh...@huawei.com> wrote: > Hi Kyle/Russell, > > -----Original Message----- > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Kyle Mestery > Sent: Tuesday, July 12, 2016 9:19 AM > To: Russell Bryant > Cc: dev@openvswitch.org; John McDowall > Subject: Re: [ovs-dev] SFC-Summary: MultiTenant > > On Tue, Jul 12, 2016 at 9:52 AM, Russell Bryant <russ...@ovn.org> wrote: >> On Tue, Jun 28, 2016 at 12:05 PM, Ryan Moats <rmo...@us.ibm.com> wrote: >> >>> John McDowall <jmcdow...@paloaltonetworks.com> wrote on 06/28/2016 >>> 10:54:31 >>> AM: >>> >>> > From: John McDowall <jmcdow...@paloaltonetworks.com> >>> > To: Ryan Moats/Omaha/IBM@IBMUS, Na Zhu <na...@cn.ibm.com> >>> > Cc: "dev@openvswitch.org" <dev@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@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
