Open Stack

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
>> “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.
>
>
Sweet!

Cheers,
Armando


> Best,
> -jay
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150618/63bd692b/attachment.html>