Working on the May Day feels like an oxymoron, but Sundays are about the only time I can clean up my overflowing Inbox.

The best post I’ve stumbled across recently is undoubtedly 38 life lessons I’ve learned in 38 years (thank you, @greg_meehan). I will try to remember the slow down one. Another great one: Managing IT people from Storagebod. Been there, seen that (and failed a few times).

And here’s the usual long list of links:

IPv6

The NAT64 drafts finally got their RFC numbers: RFC 6144 describes the framework, RFC 6145 the stateless IP/ICMP translation, RFC 6146 stateful NAT64 and RFC 6147 DNS64. There’s also RFC 6156 describing the TURN (NAT traversal) extensions for IPv6.

The IPv6 CPE requirements draft became RFC 6204. Next step: hopefully the CPE vendors (I’m looking at you, Cisco/Linksys) will wake up and realize the IPv4 address exhaustion has already whooshed by.

Stretch continues his IPv6 education efforts, this week with the description of IPv6 link-local addresses.

Data Centers

Mike Courtney is building L2 DCI (not a good idea) with Brocade gear and decided to document the configuration process (excellent idea).

Rise of IT Generalist – a bad idea? explains why the know-it-all engineers might be good enough for SMB environments (where you can’t afford to have more than one IT engineer anyway) but not for reasonably-sized data centers.

VMware Fault Tolerance, Determinism, and SMP by the Lone Sysadmin is an excellent description of how VMware FT works and why it’s limited to VMs with a single vCPU.

Brad Hedlund’s view of OpenFlow is way more optimistic than mine. Reminds me of all the enthusiasm I had a decade or two ago.

Cloudy Failures

Just in case you’ve just arrived from Mars: Amazon had a large-scale failure a few days ago, giving everyone loads of reasons to write why they love/hate/embrace/bash clouds.

Greg Ferro made a very valid observation: complex systems have complex failures that are hard to troubleshoot and recover from.

Massimo ReFerre got philosophical and wrote about UDP and TCP clouds. While I agree that the cloudy services should provide reliable infrastructure, IaaS is definitely the wrong model to do it. Reliable PaaS/DBaaS would make way more sense.

Last but definitely not least, companies offering cloud-related products simply had to tell how everyone would be better off using their software. If you skip the self-promoting part, this article is not bad.

Large-scale networks

Best practices in Network Planning is an excellent in-depth tutorial. And now imagine some people claiming they’ll do something similar with OpenFlow.