Hi Kyle,
-----Original Message----- From: Kyle Mestery [mailto:mest...@mestery.com] Sent: Wednesday, July 13, 2016 8:12 AM To: Cathy Zhang Cc: Russell Bryant; dev@openvswitch.org; John McDowall Subject: Re: [ovs-dev] SFC-Summary: MultiTenant > > 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. Cathy> In networking-sfc, a port chain is per tenant, but VNF could be shared if the VNF has multiple ports(sub-ports) although each Neutron port itself is per tenant based on Neutron API spec. [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
