View OND on GitHub

Open Network Design

OND → Accelerating Interconnectednes

Designs | Readme | About | Training Download this project as a .zip fileDownload this project as a tar.gz file

Naming Convention

Overview

Namespaces and naming conventions are a crucial part of EA(Enterprise Architecture). They allow for streamling more than just operations (albeit optimising for operations is a key goal). Conventions allow for clear and unambiguous management of logical or physical assets throughout an organization. Rather than deep dive in to namespaces, ontologies and taxonomies, there is a need for objects and their roles to be well defined, well structured, and labelled. Oftentimes an object’s expected lifetime or temporal nature influences how it will be managed. The goals of each organisational unit with respect to why and how they are identifying and naming things may differ. Whether asset tracking, troubleshooting, or describing an object and its role, there are multiple approaches and methods of encoding or surfacing characteristics quickly via their label.

Typically over the course and evolution of an organisation, the culture and thinking evolves and changes yet the assets under management (and respective linked workflows) change less often. Each team with responsiblity for managing different physical and virtual assets may have differing opinions or requirements for their respective domains, however certain default characteristsics and requirements persist across most enterprises. To allow for a naming convention that embraces all teams and organisational units (and one which does not result in years of discussion), it has been found that a mixed convention of mandatory initial characters (which entails site codes and operational/responsibility designations), and then team specific patterns ultimately satisfies the most constraints.

Asset Definition

The objects in question may represent devices, components, or other logical assets (such as virtual interfaces, virtual devices, network prefixes, even VLANs etc.).

Constraints

Also the namespace for assets must conform across facilities, finance, HR, and engineering especially for large/expensive/important assets. Essentially things are named with schemas that relate to their temporal nature i.e. how long they last (in a general location or state) and when/how often they are updated, changed, replaced, upgraded etc.

It is well known that from a network and systems context, an object’s exact location should be defined by external systems (including but not limited to tags and SNMP fields) with the one caveat that site or country codes can be encoded in to the object or optionally the domain portion of the name ‘label’ to facilitate routing, organisational boundaries, and governance. The concept of temporality (time/longevity/ephemerality) of an object and it’s characteristics or role/function also plays heavily in to the schema. The element in question, and its respective label, should optimise for permanence in asset records (thus minimizing administrative overheads throughout the lifetime of an object, system, or component!).

Goals of Asset/Resource Records

Naming conventions are crucial for lifecycle management and to ensure efficient administration. Accurate management and monitoring is one of the most immediate and obvious requirements. Additionally, one can not afford to be renaming objects constantly in documentation, DNS, or monitoring, asset management, and change management platforms. Also, as staff are onboarded, rotated, or cycle due to attrition), it’s extremely important that managed objects are unambiguously named.

Format

** Note_I ** hostnames/labels must be fixed width for certain platforms i.e. a 14 char max for the host portion as an AWS limit.

A FQDN(Fully Qualified Domain Name) example would be adn1-nfw00001a.infra.domain.net and should include subsequent interface mappings for both A and PTR records. Another example might be adn1-nfw01a-g1-1.infra.domain.net or adn1-nfw01a-t2-11.infra.domain.net whereupon the network team has elected to encode interfaces in to the name (akin to many ISPs).

** Note_II ** Exact floor, room, or physical distribution, or X,Y location should never be hardcoded in to the name as the logical representation must stay in monitoring (and it outlasts all local physical moves, adds, and changes) whilst allowing for simple DNS changes whilst moving equipment inside a building or campus. Site level or country level is the only encoding to be used in a name and all other location details should be encoded in SNMP location or other asset management fields/tags (and to some degree in the subzone if required).