<div dir="ltr">Russell,<div><br></div><div>"<span style="font-size:12.8000001907349px"> </span><span style="font-size:12.8000001907349px">These logical flows</span></div><span style="font-size:12.8000001907349px">look similar to OpenFlow, but it talks about network resources in the</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">logical sense (not based on where they are physically located).  I think</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">we can implement SFC purely in the logical space. "</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Exactly. I was in the ovn presentation at Vancouver and at that time it felt we could use these for sfc and that is why I am on this project now. I am checking if the logical flows will do what I want to do. Or we can extend the internal impl without impacting the larger neutron or other cms interaction. </span><span style="font-size:12.8000001907349px">For a standalone solutions number of flows to manage is too much with plain ovs and ovs-agent has its own limitation on how we can define custom flows..</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Missed the ovn meeting today but have notes from log. Nice usage blog :) Thank you for all you do Russell, helping us get overboard.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">-Murali</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 1, 2015 at 7:32 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.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 09/30/2015 06:01 PM, Murali R wrote:<br>
> Yes, sfc without nsh is what I am looking into and I am thinking ovn can<br>
> have a better approach.<br>
><br>
> I did an implementation of sfc around nsh that used ovs & flows from<br>
> custom ovs-agent back in mar-may. I added fields in ovs agent to send<br>
> additional info for actions as well. Neutron side was quite trivial. But<br>
> the solution required an implementation of ovs to listen on a different<br>
> port to handle nsh header so doubled the number of tunnels. The ovs code<br>
> we used/modified to was either from the link you sent or some other<br>
> similar impl from Cisco folks (I don't recall) that had actions and<br>
> conditional commands for the field. If we have generic ovs code to<br>
> compare or set actions on any configured address field was my thought.<br>
> But haven't thought through much on how to do that. In any case, with<br>
> ovn we cannot define custom flows directly on ovs, so that approach is<br>
> dated now. But hoping some similar feature can be added to ovn which can<br>
> transpose some header field to geneve options.<br>
<br>
</span>Thanks for the detail of what you're trying to do.<br>
<br>
I'm not sure how much you've looked into how OVN works.  OVN works by<br>
defining the network in terms of "logical flows".  These logical flows<br>
look similar to OpenFlow, but it talks about network resources in the<br>
logical sense (not based on where they are physically located).  I think<br>
we can implement SFC purely in the logical space.  So, most of the work<br>
I think is in defining the northbound db schema and then converting that<br>
into the right logical flows.  I looked at the API being proposed by the<br>
networking-sfc project, and that's giving me a pretty good idea of what<br>
the northbound schema could look like for OVN.<br>
<br>
<a href="https://git.openstack.org/cgit/openstack/networking-sfc/tree/doc/source/api.rst" rel="noreferrer" target="_blank">https://git.openstack.org/cgit/openstack/networking-sfc/tree/doc/source/api.rst</a><br>
<br>
The networking-sfc API talks about a "chain parameter".  That's where<br>
NSH could come in.  The spec proposes "mpls" as something OVS can<br>
already support.  Given a single VIF, we need a way to differentiate<br>
traffic associated with different chains.  This is *VERY* similar to<br>
what OVN is already doing with parent/child ports, originally intended<br>
for the containers-in-VM use case.  This same concept seems to fit here<br>
quite well.  Today, we only support VLAN IDs for this, but we could<br>
extend it to support mpls, NSH, or whatever.<br>
<br>
Anyway, those are just my high level thoughts so far.  I haven't tried<br>
to really dig into a detailed design yet.<br>
<span class=""><br>
> I am trying something right now with ovn and will be attending ovs<br>
> conference in nov. I am skipping openstack summit to attend something<br>
> else in far-east during that time. But lets keep the discussion going<br>
> and collaborate if you work on sfc.<br>
<br>
</span>I look forward to meeting you in November!  :-)<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Russell Bryant<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>