Software engineers != Hardware Engineers
Not that I disagree with the importance of getting v7 done and done properly.
Well there’s also no point in bringing out hardware, if the software to utilize the hardware, isn’t there 
Just different requirements\designs. The CCRs are great performance for the price when you’re not considering large routing tables. Whatever this platform is may have big enough cores to overcome the large routing table issue. BGP works just fine on x86 and CHR. If not, you use these boxes for MPLS and they don’t carry full Internet tables. Just stick on an x86 box for your full tables routers.
Let’s keep this thread on topic. If you must whine, elegantly incorporate it in an appropriate response to the original request.
x86 which is being phased out (and supports a few, at best hardware devices. MT even said no more new drives till the mythical v7 makes an appearance), CHR which to say the least carries piles of additional licensing fees, and misses crucial functionality. Hell, I may just as well take a trusty linux distro with Quagga, Bird or something else then I suppose. Why then bother with MT, and MT’s hardware at all (and what about the thousands I’ve already invested in hardware that promised the world and delivered everything but)? I suppose it’s much more important to rather have a ROUTER running a SMB server, or HTTP Proxy server, or even insecure DNS servers by default 
Anyways, that’s pretty much the response I expected yes. Say anything bad and you are “whining” Never allowed any criticism against MT, they can’t do anything wrong… All I’m saying, MT needs to get its priorities straight… There’s a lot of people starting to notice these… issues…
If you don’t think I criticize or allow criticism, you clearly haven’t been paying attention.
Look guys, I’m merely trying to point out that MT’s customers would be better served by concentrating their efforts on RouterOS v7 instead of releasing all these little “trinket” devices. Has anyone else noted that the newsletters are mostly full of hardware announcements? I get that hardware engineers != software engineers. That actually makes my point more strongly: it’s like MT forgot that RouterOS is the entire basis of their platform. Really, I think the argument could be made that the hardware doesn’t really matter all that much. RouterOS can run on almost anything these days.
Make RouterOS great again ? 
Take into account only a few devices have 2 power supply built-in, I really doubt you’ll do well on really high-end market. Cheap China-grade external “hey ma, I got my phone power supply for my router!” typed power sources are something that won’t look nice for anything high-end.
Who’ll pay for 100G’s while unsure in device just for its low-priced components? If so, then high-availability features must be built-in deeply into ROS. Stability and failover is the key, and MT devices used to hang sometime so far, this is blocker for high-load high-end market, too.
What you may want to do is to create 10G switches (with ASIC and ROS in it and a lot of memory, not just SwicthOS), this may be useful for poor-man clusters and some low-end datacenters, but hight-end is something different…
None of the rack mountable CCR units has an external power supply
omg you savage! =)
Ok, then lets’s count how many of them has two PSU? I suspect there is only ONE (ok, two, since one was a replacemnet for another one) When it comes to this point all I got from Mikrotik was advice to supply second power source via PoE, either via MT-compatible switch (tricky thing to find to use in rack in high-end DC) or via use PoE injector with - yes - China made cheap external PSU.
So you’re still go to high-end market?
Ok, I understand: your CCRs are so strong and reliable so you don’t even believe anyone may want to have two PSU? Then that’s good approach, but guys at huge DCs are so used to see backup PSU everywhere so they won’t get that for real.
So you may not worry for ports. Start with PSU and overall durability. Looks like your newsletters are not at all monthly, and you still have no service contracts, so it looks pretty unserious for someone who try to deal with 100G ports.
That’s not even the question of how reliable the PSUs themselves are. That’s the question of the ability to power the router from two separate UPSs and be able to keep the router running while you’re replacing the batteries in one of them.
No one argues that having two PSUs in a high-end device is a must. However this topic is about something else, right? So, please, guys, lets stay on topic here! 
But I would like a desktop unit with a single internal PSU.
Not a problem, but this is not high-end device, right? And this topic is for 100G ports, something you just don’t need in desktop unit, after all.
So MikroTik is now working on a 100 Gbit/s router. The only decision is which ports that device should support. Can we get a hint what ASIC / platform is currently used?
For first high end routers i think better is create a product with most used ports. Due to dropping of 100Ge ports price, most datacenters are replacing SFP28 QSFP etc with them.
Modular router is fundamental requirement
I think somethinf like:
-
Default:
1 x Fe Mgmt Port
8 x 10SFP+ port -
Free module Slot where customers can choose between
4 x 10SFP+ port
8 x 10SFP+ port
n x 100Gbps Port
Another requirement is to optimize the handle of bonding ports that now impact too much the cpu
Wish to look at it! Modular 13U router from Mikrotik with add-in blades full of different ports, with built-in support for hardware redundancy of CPU cards, storage.
And with (still) one internal PSU
Really, I suspect a lot of people would like to see not 100G, but simple to say modular (or at least stackable) solutions from MT. It you build decent LAN you’ll need at least 100-150 client LAN ports per closet and you have to put switches each of 24 or 52 1G ports then connect it to central unit with 10G SFP+ but - no redundancy!
So to say, I’d ask for:
- central switch (capable of hardware stack, so I can put two of them) full of 10G, that’ll have at least 2x10G or more to uplink or to interconnect to different closet in different room.
- edge layer switch capable to connect with two 10G links to these “central” switches
all of these should offer full stack of switch technologies, and good diagnostics/manageability.
To my surprise, even when we’d like to feel we have a lot of traffic in the network in fact not always we need 100G ports. What we really need is some approach to build robust self-healing system so big network in office or in datacenter won’t be affected by single device fault. So modular approach is a good thing, indeed.
By the way, modular devices are more controllable and power-efficient, so for say 10 line cards worth of 50 ports each you can use 2 or 4 PSU per chassis, not 10 (one for each small switch) and the overall robustness will be higher. Remote management will be much better when you can control the whole chassis with cards in it due, etc.
So, please, aim at modular and longer-live devices, not at cheaper “save on everything” ones!
You’'re confusing “modular” word. Modular not mean 13u or bigger router. For example ASR 1001 is a modular router and is 1u.
You can setup a 1u or 2u router with fixed ports and a module for expansion to save $$ if you need expansion
Again, remember that with big ports, you can do breakout\fanout cables to put multiple smaller ports into a bigger port. That way you can have 40G or 100G ports, but can also do 10G or 25G off of them.
I would prefer modular port cards.
for example the box should have the rj45 mgt port, a serial one and two sfp+ combo ports by default
everything else should be on the extensions cards.
you need another 8 copper ports? buy a card. qsfp for the router on a stick configuration? select the right extension card.
the cpu/chasis should only have two versions:
a full one (all cores whatever) and a reasonable one.
right now it is really painfull to select the right ccr.
one of the extension cards could use infiniband to expand to another next gen ccr to extend the ports.
and please do not forget hotswapable psu.