Open Stack

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