[j-nsp] what’s the story behind MPC5E
Adam Vitkovsky
Adam.Vitkovsky at gamma.co.uk
Sat May 21 09:15:46 EDT 2016
> Saku Ytti [mailto:saku at ytti.fi]
> Sent: Saturday, May 21, 2016 12:11 PM
>
> 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.
>
That's not the entire truth, yes XM is responsible for requests/grants but it's the XL dictating the pace at which the grants are issued.
And I doubt that the common XL can issue backpressure signal to each XM selectively based on how much traffic is receives from it.
> 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.
>
Well during DDoS attack the XL will get congested so you better be prepared for that.
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.
More information about the juniper-nsp
mailing list