On 18 June 2015 at 09:54, Jay Pipes <jaypi...@gmail.com> wrote: > On 06/18/2015 12:46 PM, Armando M. wrote: > >> On 18 June 2015 at 04:30, Jay Pipes <jaypi...@gmail.com >> <mailto:jaypi...@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 >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
