[c-nsp] ASR9k Bundle QoS in 6.0.1

[Adam Vitkovsky]

> Saku Ytti [mailto:saku at ytti.fi]
> Sent: Wednesday, June 08, 2016 8:20 AM
>
> 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.
I wouldn't think of it this way.
I'd like to think that arbitration is a different process to spraying cells onto fabric planes.
There are 4 fabric planes in ASR9k and each LC connects to these planes with several links (the speed/clock-rate and amount depends on the LC type).
I think that once access is granted for a super-frame, it is placed on one of the fabric links in a round robin fashion.


> 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
>
I think that actually both arbiters are relying each access request and access grant between ingress and egress LCs.
And that the ingress LC receives two messages and acts on either of them for the failover to be seamless.
It's like having sessions to two RRs, both will rely the same route so in case one fails you still know what to do, no need to wait for any resending.
And since both RRs/Arbiters are governed by the same decision process you'll always receive the same information from both.


> b) without central arbitration
> - LC0 will detect RSP0 failure, and will proceed to resend pending fabric
> requests to RSP1
>
As you can imagine without RRs/Central Arbiters the situation is more complex.
I think it works similar to Default MDT in MVPN.
If an ingress LC is requesting access all other ingress LCs have to hear it.
Without central arbiter everyone needs to hear everyone else's requests grants, so that each LC can perform the arbitration independently. Once again since all LCs run the same arbitration process they all elect and allow the same input to transmit in a given tick.
All this is done in-band using fabric links resources so in case fabric is congested some requests/grants might not make to their recipients since I think that these messages are actually piggybacked on data cells.


> 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 it.
>
Actually central arbiter removes a lot of complexity where independent arbiters on each LC needs to somehow distribute information about who wants to TX on which priority and only once everyone is aware of everyone else's desires they all can start arbitration.



adam




        Adam Vitkovsky
        IP Engineer

T:      0333 006 5936
E:      Adam.Vitkovsky at gamma.co.uk
W:      www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------