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