On 06/17/2015 02:24 PM, Cathy Zhang wrote:
Hi Nicolas,
Thanks for your suggestion. Yes, we can add Application ID to the
parameter of the flow classifier/filter. The next updated version will
reflect this. Actually in its existing design, the parameter field of
the flow classifier can be extended in the future to include more flow
descriptors for more granular differentiation of flows.
Per earlier suggestion from Isaku etc., we can also add a “context”
field to the service chain API. The context field will include
information such as “the encapsulation mechanism” used by the service
functions in the chain, which can be NSH, VLAN, none etc. so that the
Service Function Forwarder (the vSwcitch) knows whether it should act as
a SFC proxy or not and if acting as a Proxy, what is the chain
correlation mechanism between the Service Function Forwarder and the
Service Function.
Any comments/questions/suggestions?
My only comment is the same as the one I placed on the telco-wg service
function chaining spec [1]. That is, I don't believe this work should be
done in the Neutron API at all.
Rather, I believe these concepts belong in an entirely separate (from
Neutron) API endpoint and project. Of course, the reference
implementation of service function chaining would make calls out to the
Neutron API for "plumbing" purposes -- e.g. make me a port on this L2
network, etc.
I strongly believe having a separate project for service function
chaining is the right long-term strategy for this, since the SFC
concepts are not the same as Neutron's. SFC isn't really about
networking (in terms of connectivity). Instead, SFC is about the
*orchestration* of virtual (and sometimes non-virtual) resources into a
hot-reconfigurable pipeline for directing packets across the network.
Thoughts?
-jay
[1] https://review.openstack.org/#/c/169201/
__________________________________________________________________________
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
