Donald, >> (Maybe this helps: I’m not actually sure why in a k-element set you order >> them based <something> mod k because that would seem to produce likely >> duplicates. Since your backup option in the case of duplicates is proper >> numeric sort, why just not do that and only that? E.g. "RBridges are sorted >> in byte string ascending order by their LAALP IDs, or if they are equal, by >> their System IDs considered as unsigned integers.” But it could also be that >> it is too early and I have not yet had enough Diet Coke…) > > I believe the idea is to quasi-randomize the order. The DF election is > per VLAN and a goal is to spread the multicast traffic across the > RBridges in the active-active edge group.
It is a fine goal to randomise the order. My only observation of the current setup is that if you randomise a k-element group through "mod k” operation, you will likely have some number of collisions in the result. I don’t know enough about math to calculate the percentage. But for the sake of argument, if k=2 it seems that the likelihood of collision is 50%. And for every collision, your order becomes no longer random but simply numerical order of the identifiers. In our degenerate k=2 example it seems that in 50% of the cases you have a random order and 50% of the cases you have numerical order. I’m sure there would be other ways to randomise the order with less collisions, if avoiding numerical order is important. Jari
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
