Also a comment to Greg, that OS in your screenshots is almost 12 years old.  I know you’re not a Windows guy but Windows 7 is a whole lot more productive than XP.  You could’ve just pressed the start menu key on your keyboard once (or clicked it), typed in the word ‘putty’ and pressed enter and it would’ve launched.  Even if it wasn’t even installed and the exe was lying around somewhere on the HDD, and without any environment variables.

I think it’s a very astute feature. I definitely wasn’t aware of it.

I also found 4 pins, which I found out to be for serial communications. I’ll talk with the router later

Secondly, none of the corporate laptops i’ve used in the last three years have been reliable. They crash often and I lose work and put up with a lot of frustration. My Mac doesn’t do that – it’s a no brainer.

I am a little late to teh show here, but I am boning up on my competitive analysis and ran across your blog post here.  There are many past and ongoign debates about this kind of architecture.  To be sure, this is not a new approach for networking……just a new approach for Ethernet networking.

Both Infiniband and Fibre Channel has long supported both centralized and distributed management models along with fabric topologies.  In reality, the choice is not really between cross-bar switch and multi-hop ASICs….it is always a combination of both.  How do you think packets are switched internally on the ASIC itself.  There are only a few ways to do packet switching efficiently….one is cross bar, another is shared memory.  On the ASIC it will typically use an internal crossbar, especially with Ethernet where there is a requirement for lots of buffering on the ingress or egress port.

Then the network question is…..what is the building block size and scaling model.  port to port forwarding is much more easily managed inside a chassis which typically has a local control plane.  This means that most switches have either been a “fat tree” or “clos” fabric of discreet ASICs inside the box…..or a distributed switch model with a separate “fabric” module and line cards.  Again, the fabric modules can be either dedicated cross bar switch fabrics with line cards with the edge buffering on it….or the line cards and fabric cards are just different configurations of the same ASICs.

Brocades first “director” class switch, the Silkworm 12000 was a “fat tree” architecture where each line card carried a combination of external ports and fabric ports.  This was not a fully non-blocking architecture, but it didnt really matter for FC applications.

Infiniband has long taken this approach with a centralized subnet manager.  The nice part about the discreet asic approach is it allows for much more flexibility in what you call a switch.  For example, there are already 10k node IB fabrics.  These fabrics can be build with hundreds of small switches or 10s of big switches……and they all work the same.  Sun actuall built a 3000 port IB switch for a few large HPC customers.  In fact each “line card” had 24 IB switch ASICs on it….and each “fabric card” had something like 32 IB switch ASICs on it. 

One downside of cascading asics is that you will require many more “hops” and will add latency to the datapath.  For example, inside the Sun 3000 port switch, a single port to port switch could be as many as 7 hops internally.  IB handles this well as the per switch ASIC latency is extremely low.  Configurations such as Qfabric also handle this by limiting the total number of hops supported…..which ultimately limits the size of the fabric.

large switches with fabric boards made up of separate cross bar switches are nice because they can give you very large port count and still  maintain relatively low latency from port to port as there is really only one hop port to port across the crossbar.

Qfabric also has taken the lead from infinband….as well as the OpenFlow movement to move the path management outside of the box.  This enables a fully distributed switch architecture under a single control plane and allows for easy scaling…..alhtough the cable management is a real nightmare.  In this kind of fully interconnected mesh topology, each ToR switch also needs to connect every other ToR switch….so you get a real rats next of cables across your rack……so cable simplification is not one of its benefits.

Moving towards these hardware-centric technologies pose a LOT of challenges for workload portability … of course from a hybrid cloud perspective there is no good way to address nic policy portability today IF you go with a hardware-centric approach. But if you leave policy not contingent on hardware it is completely portable. I would tend to think extending on things like the netqueue framework so that a NIC can provide technology agnostic hardware offload from the CPU to the NIC. QBH/BR and QBG will continue to face complexities as different vendors support different aspects and have different focus. If these become more popular, they will get more complicated as we try to extend into multi-vendor environments as well as hybrid and community clouds. Not to mention they will only work on complete greenfield hardware with the exception of a tiny percent of nics deployed today. 

In my opinion, the access layer switch has always been the place where we filter, enforce and mark. As long as we can ensure performance works, this seems to me to be clearly the logical place to keep these types of policies. This way the server admin absorbs the VM Specific policies and they reside in the software layer where they are more manipulatable by vcenter or other orchestration frameworks. The Physical network is no longer the access layer, allowing the physical network to focus on implementing a security and performance framework that enforces the markings that are instantiated by the application or hypervisor switch. 

So is the plan to implement TRILL in phases (what i assume back in the day people implemented STP before it existed back in the 90s)?  
I’d think this day in age it would be all or nothing.  I see more complexity added above than just a ‘simple’ STP domain.  

Unless TRILL is some plug and play protocol that we’ll never touch like I assume people were brought to believe STP was back in the 90s…riiiiiight.