> > > I think you misunderstood - having one or more gateway per tenant does not > make Transit LS better in flow scale. > The size of a Transit LS subnet and management across Transit LSs is one > the 5 issues I mentioned and it remains the same > as do the other issues. > > Based on the example with 1000 HVs, 1000 tenants, 1000 HV/tenant, one > distributed logical router per tenant > spanning 1000 HVs, one gateway per tenant, we have a Transit LS with 1001 > router type logical ports (1000 HVs + one gateway). > > Now, based on your previous assertion earlier: > "If a user uses one gateway, a transit LS only gets connected by 2 > routers. > Other routers get their own transit LS." > > This translates: > one Transit LS per tenant => 1000 Transit LS datapaths in total > 1001 Transit LS logical ports per Transit LS => 1,001,000 Transit LS > logical ports in total > 1001 arp resolve flows per Transit LS => 1,001,000 flows just for arp > resolve. > Each Transit LS comes with many other flows: so we multiply that number of > flows * 1000 Transit LSs = ? flows > 1001 addresses per subnet per Transit LS; I suggested addresses should be > reused across subnets, but when each subnet is large >
Re-reading. The above is a wrong conclusion making me believe that there is a big disconnect. A subnet in transit LS has only 2 IP addresses (if it is only one physical gateway). Every additional physical gateway can add one additional IP address to the subnet (depending on whether the new physical gateway has a gateway router added for that logical topology.). _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
