Thanks Bruce I have one point that I would like to confirm.
On Tue, Apr 26, 2016 at 11:41 AM, Bruce Davie <bda...@vmware.com> wrote: > Darrell, > I don’t think you can handle the error of unsupported replication mode > the way it is described here: > > + <column name="switch_fault_status" > + key="unsupported_source_node_replication"> > + Indicates that the requested source node replication mode cannot > be > + supported by the physical switch; this specifically means in this > + context that the physical switch lacks the capability to support > + source node replication mode. This error occurs when a controller > + attempts to set source node replication mode for one of the > logical > + switches that the physical switch is keeping context for. If this > + error occurs, logical switches continue to use service node > + replication mode. > + </column> > > If a given logical switch spans 2 or more physical switches, and one of > them can’t support source mode replication, but the other one can, then > you’ll end up with the logical switch in a mixed state, with one switch > falling back to service node mode and the other staying in source node > mode. At this point I don’t know what happens, but clearly the controller > will not be able to report what mode the logical switch is actually in > (short of introducing an explicit “mixed mode”). > Let me paraphrase what the patch text implies, just to be sure. A physical switch keeps context regarding multiple logical switches. If a controller requests that a logical switch context on a given physical switch change its replication mode to source_node, but the capability of the physical switch cannot support it, then the logical switch context on this physical switch under discussion can only use service_node replication as presumably will all the other logical switch "contexts" on this particular physical switch. Now, with respect to the single logical switch under discussion, let say this logical switch spans 3 HVs and 2 physical switches (psA and psB) as an arbitrary example. Let assume the 3 HVs are using source node replication and psA is using source node replication. But psB can only support service node replication. This means when a BUM packet is received from the internet for example by psB, it sends the packet to a replication node to get to the other transport nodes (3 HVs and psA, in this example). Split horizon is still otherwise honored. Does it absolutely require that the other transport nodes revert to service node mode ? Can't this case still work depending on the way the designated service node behaves ? We have an actual use case in OVN where the HVs will only support source node replication. I got your overall concern that its "easier to shoot oneself in the foot" using mixed replication mode; however can we say its "recommended that all members of a logical switch use the same replication mode", rather than they must use the same replication mode ? > > I propose that the last sentence read: An NVC that observes this error > condition should take appropriate action (e.g. reverting the logical switch > to service node replication mode). > > Regarding the description of the alt_replication_mode column, I think it > could be clearer. Suggested wording follows: > > <group title="Per Logical-Switch Alternate Replication Mode"> > <p> > For handling broadcast, multicast (in default manner) and unknown > unicast traffic, packets can be sent to all members of a logical > switch. There are different modes > to replicate the packets. The default mode of replication is to send the > traffic to a service node, which can be a hypervisor, server or > appliance, and let the service node handle replication to other > transport nodes (hypervisors or other VTEP physical > switches). This mode is called service node replication. An alternate > mode of replication, called source node replication involves the > source node sending to all other transport nodes. Hypervisors are > always responsible for doing their own replication for locally > attached VMs in both modes. > Service node mode is the default (and was the only option for > prior versions of this schema). > Source node mode is an alternate replication mode that may be > configured using this column. > </p> > > <column name="alt_replication_mode"> > <p> > This column (if used) configures the alternate replication mode > for this > <ref table="Logical_Switch"/>. There is one valid value > presently, > <code>source_node</code>. > </p> > agreed > Finally, it’s not strictly necessary to give this group such a long name. > It’s a per-logical switch feature by definition (it exists in the table > where per logical switch information is configured) so you could shorten > the name as follows: > > <group title="Alternate Replication Mode”> > > (The reason that the tunnel key gets the longwinded treatment is because > it can also be configured on a per tunnel basis elsewhere in the schema). > got it > > Bruce > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
