Re: [renum] IPv4/IPv6 deployment scenarios to minimize renumbering costs - network management approach

[Fred Baker <[e-mail]>]

On Dec 3, 2010, at 7:57 PM, Brian E Carpenter wrote:

> we probably need to hear a bit more discussion before we draw firm conclusions.

OK. Read draft-iab-ip-model-evolution...

Let's all agree that the things that are actually hard about renumbering - the places where people take shortcuts that the sysadmin doesn't know about or can't change - aren't going to be affected by anything we come up with, whether it's a protocol, a data model, or whatever. So we're solving what the sysadmin can solve, and very explicitly telling people that if they don't collaborate with their sysadmin our sympathy will be short-lived. We can therefore limit our scope to things the sysadmin will systematically know and want to keep track of. We're making his job easy, and making anything that makes it hard Someone Else's Fault that he can beat them with a stick over.

I submit that this is, in some level of specificity and some level of aggregation, nodes and subnets in his network, and the ACLs, Route Maps, and DNS entries that are important to that.

I'm starting from the assumption that this management model is designed to manage numbering and nothing else. Yes, it will expand or get folded into something else related to SLAs, counters, and heaven only knows what else; For right now, that is 100% off the table. We're dealing with the cases where IP addresses or prefixes get written into <something> and might need to later be changed.

I for one am OK with presuming a protocol like DHCP as opposed to NetConf or SNMP. One of the things I'm thinking about are very small devices like sensors, and I'm not persuaded that heavy protocols are required. That said, I do believe that NetConf or whatever are options. They're just not the only options.

But back to the management model...

So I am assuming that there is a set of subnets (which have prefixes among other attributes) and a set of nodes (which have interfaces, which are in turn connected to subnets and have addresses and roles). Architecturally, I think MIF would be incredibly simpler if they did what we did with Multilink PPP: IP has an interface which in turn has a set of interfaces it depends on, and how that is handled is a characteristic of the group of interfaces. So I'm going to suggest we model it that way: an IP interface is linked to a set of physical interfaces, and might not be the only IP interface linked to that set.

                    Service Interface
            ------++--------------++-------
                          IP
            ------++------++------++-------
       IP       +---+   +---+   +---+
    Interfaces  |   |   |   |   |   |
                +-+-+   +-+-+   +-+-+
                 / \      |       |
              +-++ ++-+ +-+-------+-+
    Physical  |  | |  | |           |
    Interfaces++-+ ++-+ +----+------+
               |    |        |
               |    |        |

The illustrated IP node might have one subnet that uses both its wired and its wireless ports, with it doing an ND proxy between them (Thing on the left), and it might have two subnets on the same Ethernet (thing on the right). I'll break down and presume that every interface on IP's bottom side has a subnet; I'll presume that the address on that subnet might be a link-local address or might be in a global scope prefix. It will make things easier to talk about. Yes, this doesn't describe IPv4 unnumbered point to point connectivity, but I'll hand-wave that for the moment. It's a subnet with a magic address.

So:
	Network:
		Optional set of networks
		Optional set of subnets

	Set of subnets:
		zero or more subnets

	subnet:
		prefix
		routing protocol
		optional route announcement policy
		optional route acceptance policy
		<TBD>

	Set of nodes:
		zero or more nodes

	attributes of a node:
		set of IP interfaces
		a default set of roles (if role is not specified on an interface, this is inherited)
		<TBD>

	attributes of an IP interface:
		a subnet
		an address in that subnet's prefix
		set of physical interfaces
		a set of roles
		a forwarding ACL
		<TBD>

	attributes of a prefix:
		a string of bits
		a length
		a set of roles

Yes, these objects have methods. We can create and destroy them all. An IP interface has a method for associating it with a subnet and for disassociating it from a subnet. If it becomes associated with a subnet, we can assume it learns a prefix from the subnet and forms (somehow) an address in it. That might be implemented by SLAAC or DHCP, I don't care. If we destroy a subnet that is currently attached to a set of interfaces on various nodes, I presume that it is detached from those interfaces in the process of being destroyed. If we destroy a node, It is presumably detached from all subnets it is attached to.

What's with a network? Well, if I have a large IS-IS network, I will model that as one network containing a bunch of networks (areas) which in turn contain subnets which in turn connect hosts. Note, however, that my definition is recursive. I don't know what multiple levels of recursion necessarily means right now, but I'd rather leave the flexibility (NIMROD) than make it go away right now. I'm imagining outfits like Boeing, that might have large BPG networks connecting OSPF/IS-IS networks that in turn have areas...

There's an interaction with DNS here somewhere. We have domains full of names, those names have sets of addresses associated with them, and hosts (interfaces?) have sets of names associated with them. When we add a subnet to an IP interface that we have created on a node, we may want to add that IP address to some or all of the names of that device; we will need to track this as privacy addresses change, and remove them with the subnets when appropriate. Hand-wave...

Concept of a role: Think role-based access control. When we talk about access lists (one of the things programmed numerically instead of using names) we are saying we want to allow classes of traffic, which may for example be from a set of prefixes to a set of prefixes using one of a set of IP protocols. When we need to derive the forwarding ACL, we will want to say that we will permit only traffic that goes between things of related roles - mail can go between MUAs and MTAs, financial data can go between financial clients and financial services, and so on. In its most concrete terms, a role specifies a set of applications or data sets that a set of systems might use; it's probably more scalable to think in terms of the class of usage, and use that to mean "any of a set of applications that would be used for that", but ultimately its somehow about applications and data sets. Hand-wavy at the moment, but that's what I'm thinking about.

Concept of route policies: again, route maps are among the things programmed numerically. Again, we want to derive them. Here is can be real simple (IGPs generally pass the trash) or more complex (we may want to aggregate routes between networks, whether they are within our own network, such as OSPF/IS-IS Areas, or between our network and other networks using BGP). The announcement and acceptance policies can build on things they build on now, like community strings etc etc, if appropriate.

The difference between a host and a router is the activity of routing and forwarding. It's tempting to say a node has a binary attribute along those lines. I suspect that it will be more flexible if we say that an interface has a set of zero or more other interfaces that it may forward to. In a host, those sets are all empty; in a router, by default each of those sets normally contains the other IP interfaces on the router. However, it is possible to disallow forwarding between pairs of interfaces at will; this is often used in VRFs and such.

The process of renumbering a network is the process of creating a set of IP interfaces connecting to the same physical interfaces that existing IP interfaces do, creating subnets with the new prefix, attaching the newly-created IP interfaces to the new set of subnets, testing for correctness, and potentially later destroying a subset of the old IP interfaces (which detaches them from the subnets) and destroying the relevant subnets (which detaches them from the interfaces). ACLs and Routing policies get updated by virtue of their roles while that is happening, as does DNS.

If I'm making sense so far, I'll try digging up tools to make this a little more formal.