Open Stack

Apologize typo "...us get overboard." ==> should be "... get us onboard" :)

On Thu, Oct 1, 2015 at 11:38 AM, Murali R <muralirdev at 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 <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/cb64d24a/attachment.html>