Open Stack

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 <rbryant at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151001/24178e51/attachment.html>