Network Processing Unit in Juniper Routers

[@munkymunk]

All the network engineers coming here to get the real info! Fantastique Nicholas!

[@shawnzhsh]

great explanation, Nicolas. no one size fits all, but here one video explains the silicon industry, almost!

[@brunorijsman]

Amazing video. So much more useful and interesting than the typical fuzzy-wuzzy marketing videos.

[@pier.grossi]

Bravo, very clear and detailed ! A video each network Engineer working in an ISP should view for choosing the right device

[@mahendraladhe5188]

So much information packed in 32 minutes video, it's worth watching. Thank you Nicolas for this nice video.

[@devangharshad]

Great one Nicolas, enjoyed it as much as I enjoyed XRTutorials!

[@NicolasFevrier]

Glad to hear you liked it :)

[@afdadfasfafdsa]

Fantastic clear detail presentation

[@NicolasFevrier]

Thanks, glad to read it could be useful :)

[@ethercat.]

Great video Nicolas! Its quite rare to have such in-depth explanation of ASIC pipelines in publicly available material. From a positioning perspective, trio feels like jericho/dune, express feels like trident and Q5 is similar to tomahawk; just a rough understanding. It would be great if switching ASIC strategy (e.g. Q series) is also introduced. Again, thanks for the great content.

[@NicolasFevrier]

Thanks a lot for these nice words, glad to know this content is useful. I don't think we can compare Trio to Jericho (DNX) and Express to Trident (XGS), it's not a fair comparison, at least not in the packet treatment approach. Trio is closer to what used to be nPower ASICs in the Cisco CRS years, or FP in the Nokia world (I'm not very familiar with their architecture, so I won't go any further in the comparison). Trio is a true run-to-completion chipset composed of 160 multi-threaded PPEs, with a lot of buffering capability and flexible shared memory. Both Express and DX are pipeline architecture with potentially multi-core/multi-slices. They both have access to "deep buffer" packet memory (not the case on the XGS side, considered "shallow buffer platforms"). Also, Express and DNX present different level of flexibility in the pipeline/stage/block programmability, which makes them quite different, despite sharing some key principles. You won't find such programmability options on the XGS side, but it will be really fast :) Thanks again for watching, and I love the "Ethercat" and profile picture :)

[@MB-xg9jt]

Waouw ! amazing explanations ...

[@NicolasFevrier]

Glad you liked it

[@PankajKumar-zt8mm]

Superb...very well explained !!

[@NicolasFevrier]

Thanks a lot Pankaj 😊

[@aglongotube]

Excelent explanation!

[@NicolasFevrier]

Thanks Alexandre :)

[@anandkrishnan5425]

Great explanation. One correction, The DNX based portfolio is ACX not SCX. Thanks for the detailed video

[@NicolasFevrier]

Thanks Anand, I suppose you refer to the subtitles? They are auto-generated by YT and fixing them is a tedious process. But it should be all ok now. Thanks again :)

[@zvladov]

Dear Nicolas, I really like and enjoy very much your very detailed and well thought videos that explain key concept of networking ASICs, no matter which vendor your work for! I have a question regarding this video. At 4:16 approximately you say "The information required for packet processing is stored in large memories banks, reachable via crossbar...". By crossbar you mean the internal interconnect matrix of the PFE - i.e. the connecting link(s) between the PPE and the Memory Banks?...I ask this question because cross-bar can mean also the Fabric, which is external to the PFE...Thank you.

[@NicolasFevrier]

Hey Zvezdelin, thanks a lot for watching :) Regarding the "cross-bar", it's not related to the fabric in this context. You can picture this as a bus offering simultaneous access to all PPEs of the ASIC, to the different memory banks for processing information.

[@NeonNotch]

At 13:12 (?), you say “VoQs or queues on the EGRESS PFE” but would that be “VoQs or queues on the INGRESS PFE” since if I’m understanding correctly, the point we’re making is that VoQs are necessary BECAUSE egress PFE doesn’t really have any queues at all? Or is the point that the egress queues are so small (such as to warrant VoQs in the first place) that we want to make the distinction between actual egress queues and virtual egress queues? Sorry for the confusion

[@NeonNotch]

Also do we need back pressure abilities when using the single pipeline (e.g. the one with VoQs) or is the need eliminated at the ingress queues?

[@NicolasFevrier]

Hi, sorry the delayed answer, I didn't receive notification of the comment and accidentally discovered your question. As you understood, the queues don't exist in the egress pipeline (or in a much more limited fashion). I'm mostly trying to explain why we talk about virtual "output" queues by drawing a comparison to a two-stage buffering architecture. In a fully scheduled system, back pressure is not needed since egress schedulers are deciding what should be sent to them. Kind regards, Nicolas