[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.
Best,
-jay
More information about the OpenStack-dev
mailing list