On 30/Jul/17 15:33, Saku Ytti wrote:
> Personally I feel the obvious right answer is, that the platform > dynamically divides bandwidth numbers by active_member_count, and > programs that to the TM, if active_member_count changes, TM > programming changes. This is what Junos does on the Trio on an MX. The programming of each member link is dynamic depending on its availability. > > Like you said, requires very good balancing. But even that seems > mostly solved problem today, when you have additional abstraction > level between hash-result and egress_interface. As imbalances can be > handled by unevenly populating the hash-result=>egress_interface > mapping table. The main problem is that the load balancing code and the policing code are not really aware of each other (which makes sense as these are separate functions). If the vendors could find a way to make both bits of code aware about each other when implemented by an operator, to improve the situation. Mark. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
