[c-nsp] ASR9k Bundle QoS in 6.0.1

Saku Ytti saku at ytti.fi
Wed Jun 8 03:20:23 EDT 2016

On 8 June 2016 at 05:22, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk> wrote:
> Now that I look at the length of this post I'm thinking I should write some
> blog on this, start with basics and build up reader's knowledge step by step
> before mixing all building blocks together into complex concepts.
> As throwing some nuggets here and there like this might actually introduce
> even more confusion.

Please do. The justification offered for centralised arbiter is
failover. I'm not sure I understand this.

LC0 => RSP0 => LC1
LC0 => RSP1 => LC1

LC0 wants to send cell to LC1, it has can reach LC1 through either RSP.

Now what failure scenario will require us to have centralised arbiter
view? Let's assume LC0 decides to use RSP0 for given cell going to
LC1. But that RSP0 dies after receiving request, but before giving
grant. How we could solve it:

a) with central arbitration
- RSP1 will detect RSP0 failure, and will proceed to give fabric
grants for pending requests

b) without central arbitration
- LC0 will detect RSP0 failure, and will proceed to resend pending
fabric requests to RSP1

What did we win by adding this central arbitration complexity? It does
not seem it's inherent with in failover? I didn't think about
multicast replication yet, but maybe there is some solid argument for


More information about the cisco-nsp mailing list