Hi Bess-WG member and Authors of draft-ietf-bess-evpn-per-mcast-flow-df-election
draft-ietf-bess-evpn-per-mcast-flow-df-election moves Designated Forwarder election from the key (ES, VLAN) to the key (ES, VLAN, S, G) once per flow election is active. Section 5.1 states : "all the benefits described in Section 3.2 of RFC8584 with respect to HRW-based Designated Forwarder (DF) election, such as deterministic selection, consistency across nodes, and minimal churn, are fully applicable to the mechanism defined in this document.” RFC 8584 all, in Section 3.1, names Consistent Hashing as addressing "the object-to-server mapping problem" and declines to compare it against HRW: "these will not be considered here." draft-dikshit-bess-evpn-df-hashing-analysis takes up the comparison RFC 8584 declined, for the exact scope transition Section 5.1 declares is safe. * It defines a churn metric. * Compares HRW and bounded-load Consistent Hashing against that metric. * Evaluates both under the wide variance in multicast group popularity seen in deployed networks. * RFC 9722 and RFC 9785 already show this working group revisiting RFC 8584's DF election guarantees twice, for fast recovery and for preference-based tie-breaking. * Neither of two touches the mapping-algorithm question raised here. This is a third, narrower revision in the same pattern. It would be great to get response from the authors on whether the Section 5.1 claim rests on an analysis not included in the document, or whether it is, as I read it, an assumption inherited from the unrelated PE membership change scenario RFC 8584 was written for. The full analysis is in draft-dikshit-bess-evpn-df-hashing-analysis Best Regards, Saumya.
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
