Network for Humans

I’ve been thinking for a long time about how the whole concept of electronic networking could be made better or at least different. This post on twitter [https://twitter.com/etherealmind/status/1110280603675566081] by @etherealmind made me regather everything going on in my head and put them in this blog… So here goes…

Why Change?

To be Frank, I’m a bit lazy and tired of the nerd-ism surrounding CIDR. I was irritated by the whole static planning that needs to be done when working in Infrastructure as code to isolate and control traffic between different application groups by using CIDR. I liked the way Docker Swarm enforces Network segmentation/isolation in a human understandable manner. The VMware NSX micro segmentation using Security Groups is also nice from an Infra-as-code workflow. But both are virtual network only constructs and not applicable for the physical networking layer… I was not able to see any way out except change the way we represent the networking endpoints which in current situation is either IPv4/IPv6 or MAC. Both of which from a human reader perspective is an 8-bit number range (IPv4) or Hexadecimal (IPv6/MAC) … Neither of which I like…. So, what could be the way out… Well I got this idea and am jotting it down as is … so expect changes later

The change in Endpoint naming convention

To start with I wanted to look at a naming convention that we humans use for objects. My first iteration was to use English alphabets from A to Z which is 24 in count, numerals 0 to 9 and a few regularly used symbols found popularly on all keyboards.

Alphabets    ->    a-z    ->    24

Numerals    ->    0-9    ->    10

The nearest bit count needed to accommodate this would be 6 => 2^6=64 slots. The alphabets and numerals eat up 34 leaving us with 30 additional space for other characters. In my second iteration, I make the naming “case restricted”, then I need to reserve 48 spaced for alphabets: 24 for small caps [a-z] and 24 for Capitals [A-Z].

This would then occupy 24+24+1=58 slots leaving 6 slots for other characters… I propose we use

+

*

/

.

\

If I overlay these 6 bits per character plan on a 128-bit address space (as is used currently by IPv6), I can accommodate 21 (128//6=21) and leaving 2 bits (128%6=2). I propose to use these for type indicators that I’ll describe later…. IMO 21 slots are a reasonable count for human readable endpoint name.

Structure of the Endpoint Name

IPv4 & IPv6 are fairly unbiased and allow the network admin to structure the allotment as per their whims and fancy. This is great for static infrastructures but not great if the Endpoints are going to be dynamic and vary in both rate of change but also change in count. I propose to used a biased naming structure here so that the name can be predictable within a certain boundary and leave enough space for dynamic naming. My first iteration is to use this structure

tier

name

Slots

example

NA

endpoint type

2 bits

0

0 – public fixed

1 – public mobile

2 – private fixed

3 – private mobile

0

Celestial location

1

E (earth)

1

Latitudinal Slot

1

N

With North Pole as reference, divide latitude into 64 slices and give each slice a char code (0-61)

2

Longitudinal Slot

1

G

With GMT as reference, divide longitude into 64 slices and give each slice a char code (0-61)

3

Country

3

IND

IND for India, USA for the US, … you get the drift right…

4

zone

2

TN

The definition for this could vary by country or could just default to 00 for globally mobile endpoints

5

service provider

3

YBB

Legal owner of this endpoint responsible for this endpoint

6

user defined

10

JF-PC.home

Name that I understand and the network too

Errr! Isn’t this too complicated!

Yup… It is going to be too complicated if we use the full naming convention always. But what if I make the addressing a bit IPv6-ish and move the whole tier 0 to 5 into a `::` . The :: can be filled by the network device and user only specifies if the target is public/private and the human understandable name…. Now Users will be dealing with only names like “2::dbserver1” for private servers, “0::google.com” for public servers.

I must admit I haven’t thought this through but I guess that’s enough for this weekend. More on this later if I get any more idea…