Even though we don’t build networks with OSI products, we still use terms from the OSI model. What terms will we end up using for SDN, once the dust settles?
The previous post introduced one document that attempts to define terms and architecture, and today’s post introduces another: the ITU-T Y.3300 document. But how do these documents fit in with our fast-changing networking landscape – and what words should we use? Today’s post looks at the Y.3300 doc, and explores a few of the terms.
Other posts in this series:
Most of us don’t have a reason to read docs from standards bodies unless we’re looking for a particular standard or fact. But as long as we’re talking about one doc from the ITU-T Y-series, it’s worth a minute to set the context of what these documents are.
First off, the topic area for the Y-series is broad, but it’s all networking! The title for the ITU-T’s Y-series of documents spells out the big items:
Global information infrastructure, Internet protocol aspects and next-generation networks
Great, so the topic is global network, IP, including next-generation networks. It’s networking! Continue reading
Hank left a lovely comment on my Rearchitecting L3-Only Networks blog post:
What you describe is literally intra-area routing in CLNS.
He’s absolutely right (and I admitted as much during my IPv6 Microsegmentation presentations @ Troopers 15).
Read more ...
Everything else is getting opened up — how about rack management?
I’ll continue to update this throughout the next two days. Feel free to issue a pull request if you’re also here at the conference and want to add to this post.

Location: Open Networking User Group (ONUG) at Columbia University
ONUG currently has 6 working groups:
It is interesting and awesome to see that half of the working groups are all about Day 2 operations and management of networks. This is exactly what’s needed in the industry.
Speaker: Adrian Cockcroft

Ansible is about simple, yet powerful automation. We want to make automation easy for everyone to learn, use, and deploy, for developers, system administrators, and operators of every skill level.
Every day we hear the success stories of people who have been able to take Ansible’s powerful automation and use it to cut their IT costs, stabilize their deployments, and allow them to get back to their focus of their job rather than continually grinding through manual tasks.
On top of that, we’ve built Ansible Tower, a web interface and API that brings those same simple principles to applying command, control, and delegation to an Ansible deployment. Customers like Nike, Splunk, Grainger, and others use Tower to centralize their Ansible deployment, delegate credentials and tasks to users in a controlled manner, and allow easy self-service access to users without them knowing the specifics of those automation.
We’re always interested in making things simpler for our users, and this extends to deploying and trying Tower as well. That’s why we’ve decided to make Tower available for use with Vagrant - what’s simpler than that?
You can try out Ansible Tower in Vagrant with just a few commands.