Network Layers

murky by mrkvm, on Flickr, (CC BY-NC-SA 2.0)

Note 1: Here is a post that probably should have been written in 2012 but here we are. I have had these thoughts for a long time and couldn’t quite formulate them how I wanted.

Note 2: I have been pretty inactive in the last little while on this blog… well here is the reason: we just had child. Babies eat up cycles, thus none left for blogging.

One of many frustrations reading analyst’s take on IT as a whole is the complete disregard for any other market than the US. That’s probably not fair but there is certainly a slant towards the US market that, understandably, makes thing a little bit more hazy for people outside that market.

Perhaps most important in this is the discourse over cloud computing. One of the main talking point of the cloud apologists is that every company should strive to move everything to the cloud. The cloud is cheaper, easier to maintain, easier to deploy, infinite capacity, etc. Whatever flavour of *aaS you choose, you will be better off moving all your apps to the cloud.

For one thing, many apps just can’t move to the cloud unless a complete re-write is done, and that costs a lot of dollars. For two, regulatory situations in every country is different: having your financial data sitting in AWS just might not be possible. Three, with all the Snowden/NSA stuff that has been going on, should we trust AWS/Rackspace/what-have-you with critical/research/financial data and trust that there won’t be any snooping around? I know that I could secure the hell out of my VMs and communications, but wouldn’t that defeat the purpose of being agile in the cloud? Because in this situation, securing at the edge won’t do.

Working in Canada, the personal privacy regulations make it that there is no issues per se to store the data in a foreign country. However, should the data leak for any number of reason (including an NSA-type scenario) the company would be liable for that leak, and nowhere to pass the puck to. The world of international law is something most company in my country would be in trouble entering.

This brings the other reality for markets like mine: Volume. The reality is that we will probably never see an AWS datacenter in Canada, simply because there is no benefit, as there won’t be enough clients requiring it. Not enough people, not enough business and ultimately just fringe benefits. (From a pure technical standpoint, there are a couple of provinces in Canada that would be great for datacenters: Quebec and Manitoba. Both have cheap, clean electricity [hydro electricity], less cooling required [it gets cold here] and plenty of cheap, qualified labour.)

It might sounds like I am adverse to cloud in general, but that is not the case at all. I just think that there are use cases for it in the enterprise, and it is central to some businesses (Netflix and al.) I just don’t think everybody will turn to the cloud for everything.

I agree with Greg Ferro that there will be much more movement towards private clouds and general automation of enterprise IT. With that, DevOps concepts will become more prevalent (if not taken in wholesale) and the SDN (re)evolution can take off. I don’t think I should trust any of these companies with my sensitive data anymore, and neither should you.

Just like a number of you, I am sure, I watched Cisco’s launch for Insieme with great interest. I had read most of the pre-launch leaks with little excitement. The reality is that I couldn’t care less about 40G uplinks and port density and all the hardware bits that seems to make some analysts too excited in the crotch area. I don’t really care about a bigger, faster switch, I care about how this will all work. The result of the launch? A bit excited, a bit underwhelmed, very hopeful.

As I am reflecting on the past few months of technology announcements, and my own quest into figuring out how networking will look like and how I can manage to keep myself relevant in this context, I end up with a few things:

VMWare’s NSX is a hell of an interesting product. It really answers a lot of the questions I had towards the integration of Network Virtualization and our current infrastructure. This has not been developed by idiots and they seem to have thought through most of the issues I initially had with NV.

I can foresee push back from Network teams around the world about NSX

The vTax model for NSX worries me.

Arista somehow absolutely needed to come out with their announcement before Cisco and announced practically nothing interesting. More bits, more capacity, more, more, more . Mike Bushong summarizes my feelings exactly with regards to Arista. Arista made Cisco look absolutely like visonaries of the field while they are not.

Juniper, as usual, have very elegant solutions for the problems that we face. Very little detail on how it actually works (seems to be the marketing model for Juniper: they announce something really interesting and then it takes months to actually explain how it works. QFabric was announced the same way)

Juniper has little market weight around here past Firewalls. I can’t see myself convincing anybody to go that way for Data Center products.

Cisco needed something big. Or be perceived as a big dying incumbent, like Microsoft (which, coincidently, was their partner in crime during the Insieme launch.)

The idea behind Application Centric Infrastructure is not new, but for the first time, Cisco expressed that idea in a way that is a bit more concrete. Unsuprisingly, the team behind the UCS applied the same concepts (Policy, Profiles) to the network instead of just the compute. That makes sense, and that seems like it can work. That looks like something I can leverage and something all of us can implement.

The nagging problem, for me, is this one: How is this implemented? How does it work?

I understand that the technology is not ready for primetime and that the controller will probably ship somewhere in 2014, but that’s the most important piece. I really don’t give a damn about the Nexus 9000 series to be honest. Yes, those are nice sexy switches but they don’t make my life any easier day to day. If the 9000s enable me to do the things that ACI says it can do, I am excited, but not before I see how it is done and how it makes my life easier.

Still looking for answers. I will begin the year with a Data Center re-design based on a bunch of Nexus 7000s because that’s what we can afford, and that will take us forward quite a bit. There is not point in investing in 7700s right now, and it is too soon for the 9000s. The investment we make right now will probably last us for the next 5-7 years before we have to do something. Hopefully, in the meantime we can stop-gap with some sort of NV solution or Cisco intergrates the 7000 to the ACI ecosystem. We’ll have to see.

Wavelength Division Multiplexing works on the principle that multiplexing multiple frequencies as a composite signal you can achieve higher data rate over a single fiber optic cable.

The idea is that with different signals of different frequencies (or wavelength) multiplexed over the same fiber. In order to differentiate between each of the frequencies, certain spacing is required in the signal. The standard used for this spacing in most DWDM equipment is a frequency grid. The frequency grid is a table of all the central frequency and their associated channel. The ITU’s recommendation standard for DWDM grids is ITU-T G694.1 .

A few terms: lambda == ITU wavelength == channel center

The two most common WDM technologies deployed out there are CWDM and DWDM.

The difference between DWDM and CWDM is summarized in the table below:

DWDM

CWDM

Application

Long haul

Metro

Amplifiers

Typically EDFAs

Almost Never

# of Channels

up to 80

up to 8

Channel Spacing

0.4 nm

20 nm

Distance

up to 3000km

up to 80km

Spectrum

1530nm to 1560nm

1270nm to 1610nm

Filter Technology

Intelligent

Passive

A Wave Division Multiplexing Node has the following sections:

Multiplex-Demultiplex (optical multiplexers and demultiplexers)

Switching (array of O-E-O or O-O-O switches in add-drop or cross-connect configuration)

Local interface (transponders)

The technology used for each of those sections will vary depending on the type of system.

The Multiplexer-Demultiplexer (MUX-DEMUX from here on out) is the component that will take a number of pulses in different wavelengths (different lambdas, and thus data signal) and multiplex it to a single composite signal, and vice-versa. Not sure I could explain it better than Roget Nutt:

MUX-DEMUX

These MUX-DEMUX are essentially optical filters that combine the optical singals from each of the lambdas into the composite signal.

The switching array, most commonly in DWDM system are Optical Add/Drop Multiplexing (OADM) systems. The goal of these systems is to route lambdas in our out of the signal. This can be achieved with specific filters for each wavelength you want to drop or add to the signal, in a static manner, but there is also a dynamic way: Reconfigurable OADM (ROADM).

ROADM achieve the switching with software-controlled microelectromechanical systems (MEMS), liquid crystal, thermo optic, beam-steering switches or tunable optical switches. Once again, Roger Nutt for the architecture:

ROADM

Transponders are essentially the interface to your endpoint. The transponder will do the Optical-Electronic-Optical conversion and provide the signal to the endpoint. Examples of transponders are: SFPs, GBICs, XENPAKs, X2s, XFPs etc.

We covered amplifiers types in the last article of this series. Although not necessarily a required component of a DWDM, depending on the power of the initial signal and distance to travel it might not be required, but all DWDM systems amplify, or give you the possibility of.

Gumaste A.; Tony A. (2002) DWDM Network Designs and Engineering Solutions; Cisco Press

Nutt, R. (2013). DWDM 101 – BRKOPT-2106: CiscoLive!365

https://en.wikipedia.org/wiki/Optical_add-drop_multiplexer

https://en.wikipedia.org/wiki/Reconfigurable_optical_add-drop_multiplexer

About Network Layers

Cloud me this, or that

My Insieme 2cents

DWDM 101 part 2: WDM and Components

Response to a Response: Letter to Padmasree Warrior, CTO of Cisco

My Tools, Part 1: Terminal

Looking for Vancouver, BC contacts in IT, networking. Want to ask a few questions about the market there right now, plz retweet or msg 05:01:30 PM January 09, 2016 from Twitter for Android Reply Retweet Favorite

@BobMcCouch i'll see if I can write this down In blog format, otherwise i'll send you an email... 01:18:22 PM September 17, 2015 from Twitter for Android in reply to BobMcCouch Reply Retweet Favorite

@JimboEfx @BobMcCouch not at the moment, no. But it could be done... 06:36:57 PM September 16, 2015 from Twitter for Android in reply to JimboEfx Reply Retweet Favorite

@BobMcCouch oh yeah and we had a bug In nx-os slowing us down for months 05:54:52 PM September 16, 2015 from Twitter for Android in reply to BobMcCouch Reply Retweet Favorite

@BobMcCouch I could give you more details if you are interested 05:49:08 PM September 16, 2015 from Twitter for Android in reply to BobMcCouch Reply Retweet Favorite

@BobMcCouch worked... I don't really know about reliable ... I left shortly after implementing. It was a bit of a complicated configuration 05:46:56 PM September 16, 2015 from Twitter for Android in reply to BobMcCouch Reply Retweet Favorite

@BobMcCouch I have done it 04:46:35 PM September 16, 2015 from Twitter for Android in reply to BobMcCouch Reply Retweet Favorite

Any recommandations for enterprise-grade DWDM solution? I need about 10 x 10g links over a dark fiber.... 03:39:01 PM July 31, 2015 from Twitter for Android Reply Retweet Favorite

@wacky__2 yep, toujours au Manitoba. Prochaine destination Dans un an environ 04:49:43 PM July 13, 2015 from Twitter for Android in reply to wacky__2 Reply Retweet Favorite

First day in the brave old world of consulting.... 04:03:20 PM July 13, 2015 from Twitter for Android Reply Retweet Favorite

Technology Short Take #35 | Strategic HR on Response to a Response: Letter to Padmasree Warrior, CTO of Cisco

networklayers on Response to a Response: Letter to Padmasree Warrior, CTO of Cisco

Wes Felter (@wmf) on Response to a Response: Letter to Padmasree Warrior, CTO of Cisco

Internets of Interest for 5th September 2013 — EtherealMind on Response to a Response: Letter to Padmasree Warrior, CTO of Cisco

January 2014

November 2013

September 2013

August 2013

July 2013

June 2013

Blog Post

Uncategorized

Log in

Entries RSS

Comments RSS

WordPress.org

© 2014 Network Layers

Suffusion theme by Sayontan Sinha

Switch to our mobile site