"dev" <dev-boun...@openvswitch.org> wrote on 06/22/2016 01:07:36 PM:
> From: Ryan Moats/Omaha/IBM@IBMUS > To: Ben Pfaff <b...@ovn.org> > Cc: dev@openvswitch.org > Date: 06/22/2016 01:08 PM > Subject: Re: [ovs-dev] SFC summary? > Sent by: "dev" <dev-boun...@openvswitch.org> > > Ben Pfaff <b...@ovn.org> wrote on 06/22/2016 12:47:06 PM: > > > From: Ben Pfaff <b...@ovn.org> > > To: Ryan Moats/Omaha/IBM@IBMUS > > Cc: dev@openvswitch.org > > Date: 06/22/2016 12:47 PM > > Subject: SFC summary? > > > > Ryan, any chance you could give us a summary of the SFC ideas that have > > come out of the huge discussion on openstack-dev? I'd like to know what > > approach we're likely to pursue. > > > > (I'd be happy to hear from anyone else, too, but I think I recall that > > you were planning to take a lead here.) > > > > Thanks, > > > > Ben. > > > > I'll pull together something by EoD so that there are out there for > tomorrow's IRC meeting. > > Ryan Ok, so it wasn't as late as I thought it might be - we can go over questions at tomorrow's IRC (and I'm always looking for better solutions if people think of them!)... To date, most of the ongoing conversation has been on the openstack side in terms of what types of NFVs (bump in the wire (BiW)/L2/L3) can/should be supported. The first place where SFC intersects with OVS/OVN is in the additional tables that will be added to the OVN northbound database. SFC defines the concept of a port chain, which consists of an ordered list of port pair groups, each of which has one or more port pairs where a port pair represents the input and output ports of a particular SF instance. Traffic is routed to a port chain via a flow classifier. John's original patches proposed to make all of these separate tables within the northbound database, and while I've not found a better way to handle the port chain, port pair groups or port pairs than with new tables, I've been pushing to extend the ACL definition to allow SFC flow classifiers to be treated as ACL entries, with the action being admittance to the port chain. The second place of intersection is how these entries are converted to logical flows. The original effort proposed breaking out of the ingress pipeline and directly punting packets to the input port of a particular port pair. My thinking has been that's not a good idea because it (a) breaks the pipeline architecture and (b) creates the possibility of multicast/broadcast loops for a BiW SF. My counter proposal (and we are still discussing it) is to augment the current ingress and egress pipelines with an additional "SFC" stage added into each pipeline. - The extended ACLs would be converted by ovn-controller into logical flows that identify the port chain and port pair group that traffic that matches it needs to go to. - For the ingress SFC stage, ovn-northd would write logical flows that would do the same based on the incoming OVS port. - For the egress SFC stage, ovn-northd would write a logical flow to select the output OVS port based on bucket grouping if the destination port pair group has multiple port pairs in it. The advantage of the above (besides maintaining what I feel is a clean architecture) is that the loopback rules in table 34 can be leveraged to break the potential loops for a BiW SF by programming table 34 to drop multicast/broadcast packets that are trying to go from the output port of a port pair back to the input port of that same port pair. Since table 34 is programmed by ovn-controller directly from physical.c, my current best solution (and I'm looking for a better one) is to have ovn-northd identify these ports in the Port_Binding table by using the options field to identify the companion Port_Binding (i.e. the other port of the port pair). Then ovn-controller can use that information to program table 34 correctly. The downside of the above is that it implies storing of port chain and port pair group information as metadata and I've not yet worked out all the details for where that can be put and how to make sure it doesn't break what we are currently carrying. Ryan _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
