On 30 July 2017 at 14:35, Mark Tinka <[email protected]> wrote: >> The LACP QOS is a moot point, there's no right and wrong way of doing the >> split. > > Doubling the bandwidth because the policer programs as such each member > link is definitely the wrong way.
Agreed. Of course you can work around, and configure the MQC as desired_bw/member_count. But that breaks up badly if you lose link from LACP. 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. 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. -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
