Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization

Jason Iannone jason.iannone at
Fri Jan 6 15:25:32 UTC 2017

Hey Chris,

Size has a lot to do with policy.  For very large organizations,
regional models make sense.  Orwell had his regional divisions[1] and
Level3 has theirs[2].  TW had a domestic version of regions before
things were centralized.

I'd argue for the organizational affect of standardization.  Is
operations centralized?  Deployments should be standardized.  Is
operations distributed?  Deployments should be centralized to those
operational distributions.  Do you have the resources to centralize?
Technology research and acquisitions teams are expensive.  Engineering
teams are expensive.  Operations teams are generally cheaper per unit,
but one of the largest teams and therefore expensive.  The bureaucracy
supports whatever model you're after in a top-down way for the
proverbial 80%.

So many networks grow organically until operations break down and
leadership implements centralized policy.  Centralizing operations and
empowering the Ops team's voice is an effective way to get to a more
standardized environment.  When Ops bucks and won't support clever
(read: retarded) stuff and they have strong leadership to support
them, things have to change.

Rather than standardizing on a vendor, I support standardized
deployments.  Deployment X gets bill of materials Y.  A significant
assumption supporting this model includes well known variables that
distinguish one deployment type from another, defined by centralized
technology research, acquisitions, and engineering teams.




On Fri, Dec 23, 2016 at 1:36 PM, Chris Grundemann <cgrundemann at> wrote:
> Hail NANOGers!
> A global hospitality organization with 100+ locations recently asked us how
> to weigh the importance of standardizing infrastructure across all their
> locations versus allowing each international location to select on their
> own kit.
> My first instinct was to jump on my favorite search engine and look for an
> authoritative document covering the topic. To my surprise I have not been
> able to find such a thing. So I've begun to write one myself, and as I
> start I've realized that:
>  a) This is likely to be a document that will be helpful to the wider
> community, and
>  b) This is likely a topic that many of you have a great deal of knowledge
> and personal experience.
> If you have pointers to an existing doc, please share.
> If you have a case study, lesson learned, data point, or even just a strong
> opinion; I'd love to hear it!
> My intention is to put this together BCOP style, but with more of a focus
> on why rather than how this time around. Feel free to reply on or off list.
> Thanks in advance for your input!
> Cheers,
> ~Chris
> PS - I won't use any direct quotes without advance permission and I'll
> provide attribution to all that contribute meaningfully.
> --
> @ChrisGrundemann

More information about the NANOG mailing list