Apologize typo "...us get overboard." ==> should be "... get us onboard" :)
On Thu, Oct 1, 2015 at 11:38 AM, Murali R <muralir...@gmail.com> wrote: > 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
