[j-nsp] what’s the story behind MPC5E

Saku Ytti saku at ytti.fi
Sat May 21 07:10:43 EDT 2016


On 21 May 2016 at 04:15, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk> wrote:

Hey,

> So there are no inter XM HSL2 links on the card please?
> For it to constitute as two PFEs I would then, as per design, expect there to be a separate set of VOQs per each XM(PFE) so that each XM can backpressure towards ingress LCs independently, is that the case please?
> Also how does the backpressure work in this setup when the common XL gets oversubscribed does it signal backpressure to both XMs or does it know which XM is responsible for most of its cycles so it will issue backpressure signal only to that XM?
> If the above is not met then I would consider it as a single PFE with two discrete arbiters feeding a common XL (which I think is just asking for trouble).

Both XM connect to fabric and manage their own requests/grants, I
don't see how that's different just because you share XL.

And I don't share your worry about congestion, if XL gets congested
there is no QoS to my knowledge, you can't know who gets to use PPE's
resource and who does not, your box is oversubscribed and you need to
fix it.
I don't understand what kind of benefits you are getting by having
dedicated XL per XM, are you thinking of putting trash traffic behind
one XL, where you don't care if it's starved occasionally, because all
traffic is equally trash and then important traffic behind another XL?
If so, then I guess from your POV maybe it is single PFE and you'll
need another linecard to do this sort of planned oversubscription.

I'm very very dubious if there is business case to plan to congest XL.
I consider lookup congestion fault which needs to be fixed.

-- 
  ++ytti


More information about the juniper-nsp mailing list