RE: Labeling and naming


We are currently trying to resolve the very same issue.
So far we plan to use following scheme:

1) Device name should be concatenation of following parts:

   <2 letters of ISO country code>

Not a bad start, but somewhat unnecessary given next field.

   <3 letters of airport city code>

Doesn't scale. Not all cities where POPs end up have airports. Additionally,
do you use the closest airport, closest major airport (by what definition),
etc. Further, if you go to 4 letter airport code, then you can use the
full ICAO abbreviations and you eliminate the need for your previous field.

  KSJC = San Jose, California, US
  ELHR = Heathrow, London, UK
  CYVR = Vancouver, British Columbia, Canada
  KACV = Arcata, California, US (actually in McKinleyville, CA)

   <3 letters of location>
      to be created

Probably helps solve previous problem somewhat, but creates a certain
amount of arbitrariness that makes the naming convention harder to deal
with and tends to introduce naming errors.

   <4 letters of device name abbreviations>
      to be created -- in case of cisco: model number

So a Cisco 12008 is abbreviated how, vs. say a 12016, or a 1201?
Additionally, someone person needs to have central control of a database of
these designators, and there comes a tradeoff between specificity and viability
at some point.

In most cases, functional purpose turns out to be more desirable than equipment
type information in the host name. (Such as IBR == Internet Border Router,

   <1 letter separator>
      arbitrary decided to be capital letter X (no DNS nor arithmetic exp problems)

Hmmm... I probably would have used either U or I for that, but X is as good as
any, I suppose. Does improve readability.

   <1 letter device ordinal>
      can be hex if needed

And when you end up with more than 16 7513's in the same location, what do you
do? Do you start with 0 or 1? Do you end with 0 or F?

     USMIANOC3662X1 - Miami Lakes NOC cisco 3662
     USMIATPL7206X1 - Miami Teleplace cisco 7206
     USMIANAPJM20X1 - Miami NAP Juniper M20
     VEBRMPOP2501X1 - Venezuela, Barquisimento POP, VE cisco 2501
     VACCSCTV1010X1 - Venezuela, Caracas CANTV collocation, cisco Lightstream 1010

2) We will also create DNS zone ??? which will be used in two main ways:

   a) reverse DNS lookup, to map IP addresses into hierarchical names, like:
      This will be mainly used for tools like traceroute, etc.

   b) straight DNS lookups of devices itself, like:
      This will be used to get easy access to a device itself (through Loopback),
      and due to mnemonic nature of device name should be easy to memorize.

So far the only problem we run into with this scheme is 12 character limit
on hostnames on some boxes.

File a bug report with the vendor. The RFCs are clear that this is not valid.


I would propose a better alternative if I had one. Unfortunately, I have yet
to see a naming scheme that didn't have problems. I will say that the following
components of naming schemes I have run across tend to work fairly well:

CLLI codes for geographic locations (SNTC = Santa Clara California, JYCY =
Jersey City, New Jersey, etc.) These are the codes used to describe where
you called on your phone bill. They do scale to most international
scenarios (LNDN=London, UK, etc.)

If your network is architected in such a way that devices have consistent
functional groupings, then using that functional grouping as a portion
of the name tends to work fairly well. Usually, for example, I'm much
more concerned with getting to the router that does the particular task
than with what model of hardware it is when I'm trying to reach it. It's
much more useful to connect to ibr01.sntc01... than to C12016X01.sntc01,
because I may or may not know which 12016 in that location is the IBR
vs. some other function, and I may not be able to remember whether
that particular IBR is a 7513, 12016, or something else.

Numbering starting at 1 vs numbering starting at 0 both have their
share of tradeoffs. I prefer starting at 0, because I find most humans
can adapt to that fairly quickly. By starting at 0, you end up with
the ability to use mod 2 computations for pairs of routers. Starting
at 1, the math becomes more complex (1 pairs with 2 instead of 0 pairs
with 1).

That's my $.02.