Hi Jari, On Thu, Sep 17, 2015 at 9:22 AM, Jari Arkko <[email protected]> wrote: > Thanks for the in-depth review, Russ! Very much appreciated. > > I believe we still has to resolve what to do about the sort order. > > (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. > Also, I am not sure I understand this in Section 5.2: > > Assuming there are … k member RBridges in an RBv; ... each RBridge is > referred to as RBj where 0 <= j < k-1 > > Wouldn’t that mean that for 2 bridges you have RB0 only, because j=1 does not > satisfy 0 <= j < k-1 because 0 <= 1 < 1 is untrue. But again, it is too early > here and maybe I’m missing something. It is interesting that no one else noticed this. I agree it should either be "... j <= k=1" or "... j < k". Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] > Jari > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
