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... Ryan > > Regards > > John > > From: Ryan Moats <rmo...@us.ibm.com> > Date: Monday, June 27, 2016 at 9:26 PM > To: Na Zhu <na...@cn.ibm.com> > Cc: John McDowall <jmcdow...@paloaltonetworks.com>, "dev@openvswitch.org" < > dev@openvswitch.org> > Subject: Re: [ovs-dev] SFC-Summary: MultiTenant > > Na Zhu/China/IBM wrote on 06/27/2016 10:21:33 PM: > > > From: Na Zhu/China/IBM > > To: John McDowall <jmcdow...@paloaltonetworks.com>, Ryan Moats/ > Omaha/IBM@IBMUS > > Cc: "dev@openvswitch.org" <dev@openvswitch.org> > > Date: 06/27/2016 10:21 PM > > Subject: Re: [ovs-dev] SFC-Summary: MultiTenant > > > > Hi Ryan & John, > > > > For multi-tenancy use case, i think it is not allowed to boot VNF in > > openstack that can be used by multiple tenants. > > I am not clear about your concerns, can you clarify? > > If I can't support multi-tenant in a particular VNF, then the > solution doesn't scale from a business perspective. > > The discussion about here is how does OVN support a multi-tenant > VNF, independent of OpenStack. > > I've asked the same question of the networking-sfc spec as part > of the review, because it has to be solved there as well. > > Ryan > > > > > > > Regards, > > Juno Zhu > > IBM China Development Labs (CDL) Cloud IaaS Lab > > Email: na...@cn.ibm.com > > 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong > > New District, Shanghai, China (201203) > > > > From: John McDowall <jmcdow...@paloaltonetworks.com> > > To: Ryan Moats <rmo...@us.ibm.com> > > Cc: "dev@openvswitch.org" <dev@openvswitch.org> > > Date: 2016/06/28 09:46 > > Subject: Re: [ovs-dev] SFC-Summary: MultiTenant > > Sent by: "dev" <dev-boun...@openvswitch.org> > > > > Previous thread contents are here: http://openvswitch.org/pipermail/ > > dev/2016-June/073836.html > > > > Ryan, > > > > Trying to keep the thread to a single subject so we can knock them off. > > > > There are two cases for multi-tenancy: > > > > > > 1. The VNF is multi-tenant: This implies that a single VNF can > > exist as a port-pair in multiple logical networks. For this to > > happen the VNF has to support two features: > > * Separate management planes so different tenants can manage > > them independently > > * Ability to handle overlapping IP-Address ranges in the > > control and data planes. > > 2. The network can be logically separated into different segments > > with overlapping IP address ranges. This is one of the functions of > > OVS/OVN I thought or do I have a key mis-understanding? If a VNF has > > its logical ports in the namespace of a specific logical switch then > > there should be no barrier to multi-tenant networks - or am I > > missing something fundamental? > > > > I think 1) is a vendor issue and while we can make it easy for them > > they still need to do the work to separate the management/control > > and data planes? > > > > Thoughts? > > > > John > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
