Open Stack

On 18 June 2015 at 04:30, Jay Pipes <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?

Thanks,
Armando


> Thoughts?
> -jay
>
> [1] https://review.openstack.org/#/c/169201/


[2] https://review.openstack.org/#/c/192933/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150618/0020505f/attachment.html>