Aaron, That's a clear argument! Two comments. Aaron Brown wrote:
A network in its most reasonable XML description looks like this:
<network name="internet2"> <node name="host1"> <port name="eth0" /> </node> <node name="host2"> <port name="eth0" /> </node> <node name="host3"> <port name="eth0" /> </node> </network>
I strongly oppose the above description. It mixes naming and addressing, which is both inflexible and verbose. The following is so much better:
<node name="router1"> <port name="eth0" /> <port name="eth1" /> <port name="eth2" /> </node>
The reason: the first description describes an object by its properties, rather than its name. (It mixes naming and addressing). Doing so is bad. Beside that the description is longer, it is also less flexible. For example, what if host2 suddenly goes down, and the interface host2_eth0 is automatically flipped to host3_eth2. You probably don't want to let your client know all these implementation details, but simply like to refer to the same interface. So: we should name interfaces, independently of the host they are in. The following description is better (modification of your description):
<network name="internet2"> <port name="host1_eth0" /> <port name="host2_eth0" /> <port name="host3_eth2" />
<comprised-of> <node name="host1"> <port name="host1_eth0" /> </node> <node name="host2"> <port name="host2_eth0" /> <port name="host2_eth3" /> </node> <node name="host3"> <port name="host3_eth2" /> <port name="host3_eth4" /> </node> <link name="link2-3"> <port name="host2_eth3" /> <port name="host3_eth4" /> </link> </comprised-of> </network>
Note that I did name the interfaces (ports) generically. In your previous example, there was no way of knowing that
<port name="host1_eth0" />
was the same as
<node name="host1"> <port name="eth0" /> </node>
By simply using the same name, I now can relate them. I also included In short: name MUST NOT be context-sensitive. I think it is bad if I can only describe an interface as "eth0 of host3 in network 8". I much rather say interface "intf639" and only if required tell that it is in "host3" and that "host3" is in "network8". Of course, this requires that names are globally unique. I prefer to use opaque names (any string, without syntax requirements), as long as it is unique. URIs come to mind. Second, totally different:
Network seems to be 'domain inside of domain'. If I can subdivide my domain into 4 large networks, why can't i subdivide my networks into smaller networks? Relatedly, why can't a node exist in two networks at once? Example: layer4 overlay network or a VPN.
This is an important one. So far, I said that I prefer that network elements are only part of one network. That is by all means a convention. It is useful because it makes it easy for software to contact the domain, given a certain network element. If the network element can be in more domain, the software does not know who to contact at first. Of course, you can subdivide. However, my preference at the moment is to use different views. For example, one layer4 overlay view and a real topology view. This is not a strong preference though. It is just that I have not heard enough use cases to make the relations between network element, network, view and domain more complex than it already is in this discussion. I let it rest for a couple of days and think about your arguments. Regards, Freek