[openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining

Jay Pipes jaypipes at gmail.com
Thu Jun 18 16:54:00 UTC 2015

On 06/18/2015 12:46 PM, Armando M. wrote:
> On 18 June 2015 at 04:30, Jay Pipes <jaypipes at gmail.com
> <mailto:jaypipes at gmail.com>> wrote:
>     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.
> That's along the same lines of the comments I made on the same spec [1].
> Having said that, in my opinion to realize Service Function Chaining use
> cases more than one API (extension) is required, because more than one
> component needs to be involved (from compute all the way to networking
> elements). And yes, you do need an orchestrator for that and I don't
> believe this orchestrator is Neutron.
> The effort initiated here is an acknowledgement of this fact. The API
> (and following PoC's) underpinning this effort will be solely focused on
> the chaining/traffic classification/flow handling aspect of the broad
> SFC universe. Once it is done, it won't be complete, in the sense that
> something else needs to tell us how to create and managed the (and I
> quote you) hot-reconfigurable pipeline for directing packets across the
> network. After all, Neutron needs to understand how to direct packets
> across the network, and we cannot do that today (at least in a flexible
> and API driven manner). This is what this effort is about.
> Perhaps we should make this clearer. There a WIP proposal defined in
> [2], and it is still taking shape. It would be great if you could
> provide your input along the way.
> Do you think we're aligning in the thinking process?

OK, cool, glad to hear this. Yes, that would work for me.

And yeah, I'll review the [2] proposal.


More information about the OpenStack-dev mailing list