<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 18 June 2015 at 09:54, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/18/2015 12:46 PM, Armando M. wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On 18 June 2015 at 04:30, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>> wrote:<br>
<br>
    On 06/17/2015 02:24 PM, Cathy Zhang wrote:<br>
<br>
        Hi Nicolas,<br>
<br>
        Thanks for your suggestion. Yes, we can add Application ID to the<br>
        parameter of the flow classifier/filter. The next updated<br>
        version will<br>
        reflect this. Actually in its existing design, the parameter<br>
        field of<br>
        the flow classifier can be extended in the future to include<br>
        more flow<br>
        descriptors for more granular differentiation of flows.<br>
<br>
        Per earlier suggestion from Isaku etc., we can also add a “context”<br>
        field to the service chain API. The context field will include<br>
        information such as “the encapsulation mechanism” used by the<br>
        service<br>
        functions in the chain, which can be NSH, VLAN, none etc. so<br>
        that the<br>
        Service Function Forwarder (the vSwcitch) knows whether it<br>
        should act as<br>
        a SFC proxy or not and if acting as a Proxy, what is the chain<br>
        correlation mechanism between the Service Function Forwarder and the<br>
        Service Function.<br>
<br>
        Any comments/questions/suggestions?<br>
<br>
<br>
    My only comment is the same as the one I placed on the telco-wg<br>
    service function chaining spec [1]. That is, I don't believe this<br>
    work should be done in the Neutron API at all.<br>
<br>
    Rather, I believe these concepts belong in an entirely separate<br>
    (from Neutron) API endpoint and project. Of course, the reference<br>
    implementation of service function chaining would make calls out to<br>
    the Neutron API for "plumbing" purposes -- e.g. make me a port on<br>
    this L2 network, etc.<br>
<br>
    I strongly believe having a separate project for service function<br>
    chaining is the right long-term strategy for this, since the SFC<br>
    concepts are not the same as Neutron's. SFC isn't really about<br>
    networking (in terms of connectivity). Instead, SFC is about the<br>
    *orchestration* of virtual (and sometimes non-virtual) resources<br>
    into a hot-reconfigurable pipeline for directing packets across the<br>
    network.<br>
<br>
<br>
That's along the same lines of the comments I made on the same spec [1].<br>
Having said that, in my opinion to realize Service Function Chaining use<br>
cases more than one API (extension) is required, because more than one<br>
component needs to be involved (from compute all the way to networking<br>
elements). And yes, you do need an orchestrator for that and I don't<br>
believe this orchestrator is Neutron.<br>
<br>
The effort initiated here is an acknowledgement of this fact. The API<br>
(and following PoC's) underpinning this effort will be solely focused on<br>
the chaining/traffic classification/flow handling aspect of the broad<br>
SFC universe. Once it is done, it won't be complete, in the sense that<br>
something else needs to tell us how to create and managed the (and I<br>
quote you) hot-reconfigurable pipeline for directing packets across the<br>
network. After all, Neutron needs to understand how to direct packets<br>
across the network, and we cannot do that today (at least in a flexible<br>
and API driven manner). This is what this effort is about.<br>
<br>
Perhaps we should make this clearer. There a WIP proposal defined in<br>
[2], and it is still taking shape. It would be great if you could<br>
provide your input along the way.<br>
<br>
Do you think we're aligning in the thinking process?<br>
</div></div></blockquote>
<br>
OK, cool, glad to hear this. Yes, that would work for me.<br>
<br>
And yeah, I'll review the [2] proposal.<br>
<br></blockquote><div><br></div><div>Sweet!</div><div><br></div><div>Cheers,</div><div>Armando</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Best,<br>
-jay<br>
</blockquote></div><br></div></div>