Subject: [renum] Treating renumbering a network as a special case of managing a network

From: Fred Baker <[email-masked]>
Date: Thu, 2 Dec 2010 14:39:10 -0600

Yes, I changed the subject line. I have always been curious about why we manage boxes instead of networks, and it seems like this is an opportunity to think of renumbering a network as something about managing a network.

On Dec 2, 2010, at 1:59 PM, Fred Baker wrote:
> If you really want to follow the central management mantra, I think the right approach will be to build a management model of a set of nodes with relationships with subnets. You can subsume most hosts into subnets using DHCPv6 or SLAAC, but you will have to keep track of routers and connectivity among them and outside. You will wind up identifying specific hosts (servers) that have special attributes, such as a role (think role-based access control), and implications of those roles (if one of a host's roles is to serve financial data, it may only be allowed to talk with hosts whose roles include being a client of financial data). You will similarly want to assign roles to prefixes in BGP (which might be the same concept as communities, but I'll bet that it merely maps to communities). Given such a management model, it is a relatively simple task to derive access lists, route maps, and interface configurations, and renumbering becomes a special case of changing the dataset by adding/dropping a prefix or subnet number to/from a set of subnets, and by extension to/from a set of router and host interfaces.

Starting to think this through.

It seems like you have two sets of objects: nodes and arcs, if you will, but I'll call them nodes and connectivity. Connectivity includes:
 - LANs of any description, which will always have subnets, and may have arbitrary numbers of members.
 - point to point links, which may have subnets but have the option of being unnumbered (in IPv6, that means using only link-local addresses; in IPv4, it means using some distinguished address). 
 - overlay connectivity, which includes various kinds of tunnels, and in some respects may be treated as point to point links.

If I have a host-kind-of-node, it has two important attributes in this context: a set of instances of connectivity it is currently a member of, and a set of roles it might assume. The connectivity membership in turn has attributes: for each instance of connectivity a host is attached to, we need to know which interface(s) it uses to attach to it. Roles are basically about applications and data, but might have implications like "not reachable from outside" as a result of how roles are assigned and what rules apply to them.

If I have a switch-kind-of-node, at the Internet layer I want to think of it as a host. That said, see the SAVI framework; the switch might need to know its prefix.

If I have a router-kind-of-node, it will have the attributes of a host within two or more instances of connectivity, and additionally have the attribute of routing among those. That may imply other attributes, such as area numbers, aggregation, acceptance, and announcement policies, and so on.

If I have a subnet, I'm going to be interested to know what routing protocol is in use in it, what kind of lower layer it uses, and so on. We could start talking about aggregates of subnets, which we might call "campuses". Yes, if we do it right, we have just re-invented maps. We could also talk about a "default role"; if a host that is otherwise unknown becomes part of the subnet, what role shall we assign to it? But it certainly has a list of prefixes and a list of subnet numbers, and methods to add to or drop from those lists.

So, on one wall, I have a set of nodes, and on the other wall a set of connectivity, and I am attaching the nodes to the connectivity. The implication of doing so is that the relevant interface (identification of which is an attribute of a node attached to a subnet) gets configured in a manner appropriate to the subnet.