Hi Massimo ! Thx for your advice.
We have two reaseons to look at the new MPC Hardware. First we do have the problem, that our Peering MX-960 node slots are nearly full and we need th 16port 10G Card to replace old 4x10G DPCs. Here we have a seconde usecase where we think about using the new MPCs with 4x10G MIC. Our main goal is to use all ports of the card. Thats why we are at a "proof of concept" LAB in amsterdam at the Juniper site from 2nd to 3rd of September. We want to see if we can break the 120G Limitation by using 2ports per pfe locally without switching over the backplane. In this case the QoS Topic is not relevant as the ISP Node uses iBGP, eBGP and OSPF. So our main interest is in V6 support. The other usecase has to do with MPLS P2MP-LSP for Video distribution. We built a Network for one of our customers for video distribution and used the MX-480 and MX-960 nodes as juniper seemed to support "make before break" and the ability to add and remove leaves to the P2MP-LSP Tree without packet loss. I guess with binary MCAST replication you mean the "binary tree" juniper is talking about when it comes to P2MP-LSPs (by the way its CCC we use). Right now we have packet loss in certain situations (depending on network topology) when a leaf is added or removed from an existing P2MP-LSP Tree. Juniper suggests to solve the problem by putting a node with MPC Cards only in the network core to get rid of the problem that a binary tree is always completly recalculated when a leaf is added or removed. So if i understand you right you say that by putting a DPC into a MPC only Node, the MPC Cards notice the DPC and treat P2MP-LSP in the "old fashion" using the binary tree again. did i understand this correctly ? greetings Gerhard Wir haben neue Telefonnummern und E-Mail Adressen. Bitte aktualisieren Sie den Kontakt. Dipl.-Ing. Gerhard Prochaska Fixed Network Planning Core Development, Implementation & Supp A1 Telekom Austria AG Arsenal 22 Obj. 22 A-1030 Wien M: +43 664 66 25690 T: +43 50 664 25690 F: +43 50 664 9 25690 [email protected]<mailto:[email protected]> www.A1TelekomAustria.at<http://www.a1telekomaustria.at/> Firmensitz Wien FN: 280571f Handelsgericht Wien P Bitte denken Sie an die Umwelt bevor Sie dieses E-Mail ausdrucken! ________________________________ Von: magno [mailto:[email protected]] Gesendet: Freitag, 27. August 2010 01:09 An: Prochaska Gerhard Betreff: Re: [j-nsp] New 16port 10G Card and new MPC with 4x10G MIC Cards - coexistance of old DPCs and new Cards in same chassis -- looking for experience feedback hi Gerhard! I have never used a mixed TRIO - IChip MX, so I can just advice some 'theoretical' concepts to keep in mind: 1) Feature Set: TRIO today is much less rich from a feature set standpoint than I-CHIP. If you need a feature supported on I-CHIP but not on TRIO, you MUST be sure that the whole traffic in both directions that needs that particular feature will be managed on a single PFE (this concept applies also the other way around, for feature supported by TRIO and not by ICHIP). If the traffic needs to be switched throughout the fabric on different kind of DPCs/MPCs only the feature supported by both TRIO and I-CHIP will be supported; 2) Multicast Replication: the enhancement to the binary mcast replication introduced on TRIO won't be available in mixed mode, therefore the legacy binary replication I-CHIP style will be used; Hope this helps to clarify better this topic. Cheers Max. On Thu, Aug 26, 2010 at 1:10 PM, Prochaska Gerhard <[email protected]<mailto:[email protected]>> wrote: Hi ! We are planning to mix DPCs and new Linecards in the same chassis. As far as i understand this is possible from Junos 10.2R2 upwards. We plan to use both types of cards to increase port density on our ISP Nodes where we are short of free slots. So from the Service Point of View iBGP. eBGP, OSPF and Carriers Carrier are the main topics. Im looking for feedback what problems other providers have already encounterd. >From reading the posts ist seems that even in an environment with new MPC >Cards only Release 10.2p2 is not ready for use in a service provider >environment ? Thanks for any feedback. gerhard _______________________________________________ juniper-nsp mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
