On 06/13/2015 06:12 PM, Salvatore Orlando wrote: > Second, much of the flows currently programmed by ovn-controller > would be useful for provider networks. We still want to implement port > security and ACLs (security groups). The major difference is that > unless the packet is dropped by egress port security or ACLs, it should > be sent out the physical network and forwarded by the physical network > infrastructure. > > ovn-controller would need the equivalent of the current OVS agent's > bridge_mappings configuration option. ovn-controller is > currently configured by setting values in the local Open_vSwitch > ovsdb database, so a similar configuration entry could be provided > there: > > $ ovs-vsctl set open . > external-ids:bridge_mappings=physnet1:br-eth1,physnet2:br-eth2 > > ovn-controller would expect that the environment was pre-configured > with these bridges. It would create ports on br-int that connect to > each bridge. > > These networks also need to be reflected in the OVN databases so that an > OVN logical port can be attached to a provider network. In > OVN_Northbound, we could add a new table called Physical_Switch > that a logical port could be attached to instead of Logical_Switch. > > > The provider network is still a logical network. I am not able to see a > reason for having to attach a logical port to a physical switch. Can you > explain?
Yeah, maybe the addition of "Physical_Switch" doesn't make any sense. Now that I'm coming back to it, I'm not sure that makes as much sense as just attributes or "Logical_Switch". > It seems that you are trying to describe the physical network the > logical network maps to. This makes sense, but since in Neutron then we > also have the "multi-provider" extension, which is a generalization of > the provider network concepts, would it make sense to consider some sort > of logical network bindings? These bindings might express for the time > being vlan mappings, but in the future they could be used to specify, > for instance, VTEPs or the encap type the tenant network implements. I > know this might be nonsense, but at first glance it seems a viable > alternative. That's interesting. I need to look into what "multi-provider" provides in more detail. <snip some additional feedback pointing out that Physical_Switch probably doesn't make sense> > This would have an impact on the OVN_Southbound database, as well. > No schema changes have been identified. Entries in the Bindings > table would be the same, except that the UUID in the > logical_datapath column would refer to a Physical_Switch instead > of a Logical_Switch. The contents of the Pipeline and the > flows set up by ovn-controller would need to change. > > > Would we need chassis entries also for the bridges implementing the > mapping with physical networks, or do we consider them to be outside of > the OVN realm? I was proposing that info to be in the Open_vSwitch database, as that's where the other OVN configuration entries live that are local to the node. I don't think the bridge mappings are useful anywhere else. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
