[c-nsp] ASR9k Bundle QoS in 6.0.1

[Adam Vitkovsky]

> Saku Ytti [mailto:saku at ytti.fi]
> Sent: Wednesday, June 01, 2016 12:50 PM
>
> On 1 June 2016 at 12:45, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
> wrote:
> > Got a confirmation from Xander, so in summary:
> > Each RP has 2 fabric chips, but both controlled by one common RSP Arbiter.
> > There are two RP cards in the chassis - so two Arbiters.
> > Only the Arbiter on the active RP controls all 4 fabrics.
> > However both Arbiters are getting the Fabric access requests in order
> > to know exactly the whole state of the system at any given time so the
> > failover can be instantenious.
> > There is no keepalive between the Arbiters but the RP's have a "CPLD"
> > ASIC and one of its functions is to track the other RP's state via low
> > level keepalives.
>
> What about say 9922 with lot of fabrics? It seem completely odd to me why
> you'd want to even design centralised arbiter, instead of per fabric arbiter.
> Each linecard connects to all fabrics and balance between fabrics. I don't see
> why fabric1 would care about fabric2's situation.
>
It's not like fabric1 cares about fabric2.
It's merely about whether the FIAs exchange fabric access request and grants directly between each other via in-band (crossbar links) in which case each egress FIA would be responsible for arbitrating access to its resources (Juniper MX).
Or whether FIAs relay these messages via out of band links through primary and backup central arbiter.

Arguably there are some benefits in using central arbiter but I'm not really convinced.

The 9922 and 9912 are different beasts as they use 3-stage midplane design much like CRS.
And my understanding is that they don't use central arbiter approach .
I assume they use same/similar concepts as J-MX or C-CRS, I'm not sure.
So for what it's worth they may not even use VOQs and arbitration and might as well use egress speedup, output buffers and explicit backpressure like CRS.
I don't know.

> What you're saying does not really make sense to me, it implies that fabric
> request to fabric1 is sprayed to all fabrics in the system, why? What did we
> gain? We're multiplying the request volume by the number of fabrics we
> have, limiting how many fabrics we can insert.
>
In case of a central arbiter there are out of band links to it. So the requests are sent only to two arbiters (primary/backup).


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
---------------------------------------------------------------------------------------