[openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
armamig at gmail.com
Thu Jun 18 16:55:45 UTC 2015
On 18 June 2015 at 09:54, Jay Pipes <jaypipes at gmail.com> wrote:
> 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
>> field to the service chain API. The context field will include
>> information such as “the encapsulation mechanism” used by the
>> 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
>> 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 . 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
>> That's along the same lines of the comments I made on the same spec .
>> 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
>> , 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  proposal.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev