Open Stack

Hi Cathy,

See inline...

On Tue, Oct 4, 2016 at 2:36 PM, Cathy Zhang <Cathy.H.Zhang at huawei.com>
wrote:

> Hi Tim,
>
> Please see inline.
>
> Cathy
>
> -----Original Message-----
> From: Tim Rozet [mailto:trozet at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161005/32c84eab/attachment.html>