Open Souce Network Operating Systems

[ray at oneunified.net (Raymond Burkholder)]

On 01/17/2018 07:48 PM, Hugo Slabbert wrote:
> On Wed 2018-Jan-17 23:11:14 +0000, Matthew Smee 
> <matthew.smee at sydney.edu.au> wrote:
>> Yeah, it'd be silly for organisations to try and standardise their 
>> environments for services or infrastructure.

Was this spoken tongue-in-check, or in all seriousness?

I would say there is power in standardization.  And, yes, there is risk 
depending upon your attack surface.

When we concern ourselves with the attack service, how much time do we 
spend on mitigating issues on the edge (the attacked surface), vs 
internal infrastructure where we can apply labour and effort saving 
automation and orchestration?

> 
> I'm somewhat in two minds there.  Options to tackle operational 
> complexity/expense:
> 
> Option 1: Require a homogeneous environment or minimize 
> vendors/platforms as much as possible.

Maybe deal with on a case by case basis?  Or implement solutions which 
are 'easy' to mitigate?

> 
> Option 2: Accept vendor/platform diversity as inevitable and build 
> systems/abstractions around that.

And do this in an intelligent manner, depending upon management and risk 
profiles.

Infrastructure tends to be wide ranging.  When one thinks about the big 
picture, where do you _really_ need the diversity, and where you can you 
gain the most by standardization?  Standard engineering response:  it 
depends.

And I hope that readers are not trying to draw a line in the sand.  I'm 
hoping that we are open to optimization and orchestration based upon the 
infrastructure at hand.

> 
> Is #1 achievable?  If you're expending time/effort/resources achieving 
> #1 and fall short, don't you have to do #2 anyway?

Doesn't this go the other way?  ... that if you are spending so much 
effort that building infrastructure, and you can't get a 
maintainable/upgradeable/orchestratable solution in place, is #2 relevant?

> 
> Much has also been said on monocultures in infrastructure: having a 
> single bug impact all of your gear sucks.  If I can manage a pair of 
> border routers, for instance, from two different vendors in an 

but when I think about this, I'm not thinking about just border routers, 
I'm thinking about core routing, virtualization infrastructure, carrying 
customer private circuits, delivering traffic to individual customers, 
gear for telemetry, implementing security, ....

When you think about all the devices involved in various levels and 
styles of service delivery, there are ways to make that homogenous, and 
much of it has various attack surfaces, and, well, vendors have their 
strengths and their weaknesses, so ...

#1 a homogenous network makes it easier to intimately understand the 
possible weaknesses, and attempt protection mechansims, but for

#2 with multiple vendors, the effort on platform education increases, 
depending upon the size of your shop, ...

> abstracted/consistent enough manner that I don't deal with their 
> idiosyncrasies on a daily basis, am I not better off than running a 
> single platform / code train in that function?

or across many functions?

> 

-- 
Raymond Burkholder
ray at oneunified.net
https://blog.raymond.burkholder.net

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.