Hi Cathy, See inline...
On Tue, Oct 4, 2016 at 2:36 PM, Cathy Zhang <cathy.h.zh...@huawei.com> wrote: > Hi Tim, > > Please see inline. > > Cathy > > -----Original Message----- > From: Tim Rozet [mailto:tro...@redhat.com] > Sent: Tuesday, October 04, 2016 1:29 PM > To: Cathy Zhang > Cc: OpenStack Development Mailing List (not for usage questions); Sridhar > Ramaswamy; Sripriya Seetharam; Anil Vishnoi > Subject: Re: Removing required port-id from classifier > > Responses inline. > > Thanks, > > > Hi Cathy, > I recall a while back discussing removing the required neutron port-id > from the classifier. > > Cathy> Do you mean logical source port here? > trozet> yeah the neutron_source_port seems required. > > Cathy> This is only required if the backend is OVS SFC driver (not > required if it is ODL SFC driver or other drivers). There are several > reasons for this. For example, without neutron source port being specified, > we have to install flow classification rules on every compute node to catch > the traffic flow from the source and scalability will be a big issue if > there are thousands of compute nodes. Another example is that if two > tenants use a shared network and each has its flow originating from > different source VMs and going through its own SFC in the shared network, > OVS needs different logical source ports to distinguish different tenants' > traffic flow. Is there any reason why you can not specify a neutron source > port? > The reason is - this restriction makes orchestrating service-chains very, very difficult :( With Tacker VNFFG feature you can neatly describe your waypoints and classifier in a TOSCA yaml descriptor. Now, this restriction forces the "operator" to select a specific neutron-port uuid among the possibly 100s of ports as a "source". This negatively impacts usability and dilutes the benefit the orchestration solution brings. If scalability is an issue, instead forcing the higher layers to pick a specific source-port, I'd suggest n-sfc team to look into coarse-grain "source identifier" - like CIDR, neutron-network, etc. You should be able to figure out specific compute-hosts where such VM's vif getting plugged into neutron and apply the classification rules only on those compute nodes? - Sridhar > > > We just finished up implementing VNFFG in Tacker and are hitting this > while testing. What is the plan to remove this requirement? Also, how are > IETF SFC/NSH related API/plugin changes going? Can we expect to have > attributes like path-id, encap type soon? > > Cathy> The API already provides a way for specifying "path-id" and encap > type (currently only MPLS encap type is supported since OVS does not > support NSH yet). As to NSH support, the code patch is being worked on, not > completed yet. We are also tracking the NSH work in OVS and hope OVS will > support NSH soon so that when networking-sfc integrates with that new > version of OVS, NSH can be supported properly. > trozet> OK good. Anil is close (demoed at ODL summit) a networking-odl > driver for networking-sfc that supports NSH. > Can you link the patches or point me to who is working on the NSH support > for the API/plugin DB layer? > > Cathy> Here is the patch link https://review.openstack.org/#/c/373465/ > > > > > Thanks, > > Tim Rozet > Red Hat SDN Team >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev