Le samedi 01 mars 2008, Freek Dijkstra a écrit :

Aurélien Cedeyn wrote:

...

I send you a little document that i made which describes a new object in the NML : the model object. All the description and motivation about this addon are in the attached document.

Aurélien, thank you so much! Very good write down! These are the contributions that will help the NML workgroup a lot.

Hi Freek, What an impressive mail :) I'll try to answer shortly but clearly to your questions.

I wholeheartedly agree with what you write, although I use different terms, and I don't understand all details of what your propose yet. Allow me to ask a bit, so I'll understand.

...

The NML goal is to instance modelisations of the real topology. This real topology is too complex regarding the description needs of applications, some informations are not needed.

True, and true. But I think that modelling of the real topology is only ONE OF the goals of NML. What you write is that you also like to see NML capable of describing "modelisations" of the real topology (I would call it abstractions of the real topology). I wholeheartedly agree that that should also be another goal of NML.

First a rather academic remark: what exactly is a "real topology" and a "modelisation" or "abstracted" topology? Most network engineers, even when asked for the "real topology" will describe fibers and devices, but still abstract a lot: they often leave out patch panels, and the internal workings of devices itself: because they either find it irrelevant (decribing patch panels is only relevant if you care about inventory management, or power loss details) or because they simply don't know the information (few people know how exactly devices work on the component level). In short: nearly everything is already a "modelisation", although the level of abstraction greatly differs between each model, and it is there where the discussion starts.

Exactly, that's what i mean with "Modelisations". The question is : "Does NML have to provide the extrem details of a real network such as patch panel ?"

You propose an object "Model" for the abstraction of networks. So far I've seen "network", "domain" (in the perfSONAR schema), "abstract_link", "topology_point" (in cNIS), "AdminDomain", and "NetworkDomain" (NDL). I'm trying to figure out how these relate.

Your examples seems to imply that there can be multiple Model objects for each domain, one for each abstractions. So the first example has a model with the layer 2 devices in a network, and a model with the layer 3 device in the same network. Is that correct, or is it a model describing the layer 2 switching capabilities and a model describing the layer 3 switching capabilities (rather than the layer 2/3 devices). The functionality compares to a single AdminDomain in NDL plus two SwitchMatrix instantiations (describing respectively the layer 2 and layer 3 switching capabilities), although the object relations are slightly different.

Your second example is a new thing, which I have not seen before in one of the schemas discussed on this list. You seem to describe filtered views of a network. That is an interesting idea, but it seems different from an "abstracted view" of a network. In my opinion, a filter only describes part of the resources, while an abstraction describes the functions of all resources, but leaves out implementation details.

Finally, while you did not describe it in text, your picture has a very important concept: you want to relate the network description (interco information) to other resource descriptions ("cluster information" and "frontend information"). I take it that is a similar concept as what Cees de Laat is presenting that -in that case RDF- can be used to link together different resource descriptions (see e.g. slide 20 presented at OGF 20, http://staff.science.uva.nl/~delaat/talks/cdl-2007-05-07.pdf)

These are 3 different examples (describe capabilities, describe filtered view, link resources together), I at first did not understand the relation and what exactly a "Model" object represents. Am I correct that a "Model" simply means "a collection of resources"? If so, do you propose that the NML workgroup only describe this "grouping" object, or would you suggest to describe also dedicated grouping objects (e.g. also a "network" or "domain" object that describe specific groups of resources).

For me, the "Model" object groups objects which have relation between each other, they are "connected". Moreover, this group represent the network itself with a particular point of view. I think that with this concept we will be able to view cloud or a black-box as a network. Because whatever how deeply you describe your network, some information will be masked (constructor specs or some information you can not get). I don't know if i answer to your questions, if not, feel free to ask me again.

Regards, Freek

(PS: sorry for the long mail)

-- Aurélien Cedeyn Comité Technique Grid'5000 Lyon Bureau 364 Nord Tel: +33 4 72 72 82 30 Laboratoire de l'Informatique du Parallélisme (LIP) Ecole Normale Supérieure de Lyon 46 Allée d'Italie 69364 Lyon Cedex 07 - France

Evangelos wrote about the "Model" object:

Can we call them "Views" instead of "Models"? "Model" is a quite overloaded word, especially in a semantic context.

But otherwise, thanks for writing this up. This is really close to work currently under development in the IDC project.

Currently, I see two concepts here: an (administrative) network domain, and a filtered view. The relational difference is that a device can only be part of ONE "domain", but part of MULTIPLE "views". Evangelos, does that mean you like to have both a "domain" object for grouping, and another "view" object that gives you a filtered view of the contents of this group? Or do you only want one "View" object that is just some grouping of network elements? Do we need a third "network" concept for grouping, besides (or instead of) "domain" and "view"? If so, what would be the relation between devices and such "network" and how is that different from "domain" or "view"? Did the IDC project made such choices already? (My opinion: I like to see at least an (admin)domain object, and possibly a "view" object. I don't yet see a need for a "network" object different from a "domain" object. Nevertheless, Aaron presented exactly those two, and I love to hear that argument). Aurélien Cedeyn wrote:

For me, the "Model" object groups objects which have relation between each other, they are "connected". Moreover, this group represent the network itself with a particular point of view. I think that with this concept we will be able to view cloud or a black-box as a network. Because whatever how deeply you describe your network, some information will be masked.

I think that a "domain" object (with each device only part of one domain) can already have this black-box abstraction. However, the "view" object is more flexible, and allows either a more detailed view (a network domain with some more details described) or a more abstract view (two or three domains abstracted as a single cloud) -- I am not sure how that would work in practice though, so suggestions are welcome.

"Does NML have to provide the extreme details of a real network such as patch panel ?"

My opinion: no, but it should be extensible enough so that someone may later do that. (Perhaps by describing them as "devices" without switching capability, or by introducing a new object). Regards, Freek

Freek Dijkstra wrote:

Evangelos wrote about the "Model" object:

...

Can we call them "Views" instead of "Models"? "Model" is a quite overloaded word, especially in a semantic context.

But otherwise, thanks for writing this up. This is really close to work currently under development in the IDC project.

Currently, I see two concepts here: an (administrative) network domain, and a filtered view. The relational difference is that a device can only be part of ONE "domain", but part of MULTIPLE "views".

Agreed.

Evangelos, does that mean you like to have both a "domain" object for grouping, and another "view" object that gives you a filtered view of the contents of this group? Or do you only want one "View" object that is just some grouping of network elements? A "view" can be more than a simple grouping or filtering; it could be a complete restructuring of the network elements. The most common use case in the control plane world would be reducing a network to a simpler topology, and possibly obfuscating device and interface names, to safely provide the data to an untrusted party.

In general, a domain might offer different views of its topology with varying complexity and parameters, each targeted to a different class of applications. I think that's what Aurelin is shooting for, and I think it's a great idea. Anyway, here's what I think that sort of structure would look like: - Domain --- View (type = "monitoring") ------ Network Element ------ Network Element -------- Network Element ------ .... --- View (type = "controlplane") ------ Network Element ------ Network Element ------ .... --- View (type = "export") ------ Network Element -------- Network Element ------ Network Element ------ .... and so on and so forth.

Do we need a third "network" concept for grouping, besides (or instead of) "domain" and "view"? If so, what would be the relation between devices and such "network" and how is that different from "domain" or "view"?

I'm on the fence as to whether we need a separate "network" concept. We might need to model administrative domains that run multiple independent networks. Examples: the GEANT testbed network vs the GEANT production network, or ESnet Science Data Network vs ESNet IP core vs ESnet optical testbed. Devices may belong to multiple of these "networks", too. I kindof think that each of these may be safely modeled as an administrative domain of its own, but that breaks the device->single domain relation. Or, we can describe each with its own View, which makes for a simpler schema but may not be 100% semantically correct. Any feedback is appreciated.

Did the IDC project made such choices already?

(My opinion: I like to see at least an (admin)domain object, and possibly a "view" object. I don't yet see a need for a "network" object different from a "domain" object. Nevertheless, Aaron presented exactly those two, and I love to hear that argument).

We haven't made hard choices per se. We're working on automatically "abstracting" network topologies for export. The abstracted view of the topology needs to be made persistent.. so we came up with a database construct similar to the above.

Freek Dijkstra wrote:

Evangelos Chaniotakis wrote:

...

I'm on the fence as to whether we need a separate "network" concept. We might need to model administrative domains that run multiple independent networks.

You totally convinced me. So:

DOMAIN = administrative domain = an organisational entity that is responsible for the operational control of resources (including network resources)

NETWORK = a collection of network elements that behaves as a single resource (it is possible to describe the functionality without exposing the internal implementation or detailed internal limitations)

So how would a network in this context be meaningfully different than a node? A node is some entity with a set of interfaces to the outside world. With this definition, a node could correspond to a domain, a network element, some arbitrary group of network elements, etc. Basically, as long as it's a thing or group of things with a set of interfaces to the outside world, it can be reasonably described as a node. The major benefit of the node model is that there's no real difference between specifically described elements and summarized elements. They look like nodes with interfaces and links in both cases which on some level is true. No matter how specified you've gotten, you're going to be summarizing something (e.g. in a router, you'd have a number of logical node-entities interconnected with a bunch of logical links, all of which is abstracted away behind a 'node'). It also analogizes to how the links are summarized. A high-level link is made up of a bunch of lower level elements underneath in the same way that a high-level 'node' is made up of a bunch of lowel level elements. In this view, you might have elements like so to describe the nodes in a certain pop connecting esnet, geant and canarie: <domain name="Internet2"> <!-- the definition of the physical elements --> <node name="ciena1"> <port name="eth0"> <link name="link_to_ciena2" /> </port> <port name="eth1"> <link name="link_to_ciena3" /> </port> <port name="eth2"> <link name="link_to_esnet" /> </port> </node> <node name="ciena2"> <port name="eth0"> <link name="link_to_ciena1" /> </port> <port name="eth1"> <link name="link_to_ciena3" /> </port> <port name="eth2"> <link name="link_to_canarie" /> </port> </node> <node name="ciena3"> <port name="eth0"> <link name="link_to_ciena1" /> </port> <port name="eth1"> <link name="link_to_ciena2" /> </port> <port name="eth2"> <link name="link_to_geant" /> </port> </node> <!-- the definition of a pop --> <node name="pop1"> <port name="virtual_eth0"> <link name="virtual_link_to_canarie" /> </port> <port name="virtual_eth1"> <link name="virtual_link_to_canarie" /> </port> <port name="virtual_eth2"> <link name="virtual_link_to_geant" /> </port> </node> </domain> Then, you pass around pop1 to the interested parties as well as give it attributes the same way you might give a node attributes (who is the administrator for this pop, etc), and if they so desire, they can look up the elements that actually make up the pop (those pointers would be included in each of the elements, but they're left out of the example for brevity). The virtual ports could also include as much information as the physical ports that make them up so that they could easily be used for path finding or whatever. I think the view model is a great idea for getting a specified slice of a set of elements(what are the elements I need to monitor? what does a layer3 view of the network look like?). I'm just not sure it's the best as a summarization technique. i.e. why should it be materially different for me to do pathfinding if i have a full network topology information (nodes + ports + links for everyone) vs. summarized network information (my nodes + ports + links and views for everyone else's topologies). What are people's thoughts on this? Cheers, Aaron

Evangelos Chaniotakis wrote:

I agree, but I say: formalize that pop1 is the "abstracted" view and the rest are the "detailed" view. If we did that, a network information DB could hand out that single document and applications would select the view that's most appropriate for their demands and capabilities. In the snippet above, there is no way to tell if pop1 is a real node or a "virtual" node. (and, if you start labeling things, you end up doing something quite similar to views)

And as far as treating domains and networks as generic Nodes with interfaces poking out: No problem, and I don't see it conflicting with the domain / view / network model. They could (and probably should) all have the NetworkNode aspect.

So, if one is creating a specific view, why is it being limited to a view of a single administrative network? Couldn't I create a 'view' of the set of pinger measurement points where the set of nodes spanned across a large number of administrative domains? I think the view concept is really the same as the 'group' element that we discussed at OGF. It's basically a grouping of various network elements that have some relation. Defining what this relation is in a view seems to depend on the context. Say a user requests all the views that i've defined. How does it know which one to select? i.e. How do we assign meaning to this arbitrary grouping of elements. Once we've defined on how to assign meaning to these groupings, I think the difference between a group and a view goes away. I.e. how is "i know what group X means" different than "i know what view X means"? Cheers, Aaron

Hi Aaron, Good points. To me, a "Node" is a network element with switching capability and interfaces. I love that concept. "Network" and "Device" classes are subsets of the more generic "Node" concept. (Subclasses in a UML relational diagram.) A Device is a Node with some additional properties (for example a device has a Location, while a Network is not bound to a single location). If we want to have a "View" object that can also describe network elements in multiple domains, all I can think of is just a "Group" (of network elements), but NOT a Node subclass. (Feel free to counter this argument. Maybe my imagination is limited!) Both "View" and "Network" are groupers. Groups exist only because we humans like to talk about them and refer to them. We like to abstract things, and that is very useful. A path finding may ignore these groups and only looks at the switching capabilities (I've got a path finding that totally ignores devices and domains, and only looks at interfaces, adaptations and switch matrices). In my view, the difference between "View" and "Network" is that a network element can only be in ONE "Network", but can occur in multiple "Views". This is an arbitrary distinction, but to me a very useful one. The restriction of network takes away a bit of flexibility, but in return my control plane software becomes much more simple. And I like that. To summarize: Device: a node, not a group. Network: a node, a group. A network elt. can be in only 1 network. View: not a node, a group. A network elt. can be in multiple views. Are we missing something? Perhaps Aurélien's Model concept: Model: a node, a group. A network elt. can be in multiple models. (if I understood correctly, that is) I'm currently fine with "just" the above 3 concepts. Regards, Freek

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

John Vollbrecht wrote:

This has been a great thread, and I would like to throw in a couple ideas about how DCN setup works or could work to get your ideas.

First - There are a couple cases where the obvious way of describing a network doesn't work for DCN. Case 1 - We have a network with an ethernet interface to a switch. The switch is statically configured to take some VLANS to one endpoint and other VLANS to other networks. The way we have talked about handling this is to create a separate link for each VLAN group.

I am not good at XML so I will write this as

domain=Internet2 node=Boston-Ciena port = ethenet-A link = bu.edu

domain=Internet2 node=Boston-Ciena port = ethenet-A link = tufts.edu

Now in the properties (I think) for each link will be included the allowable VLANS. My question is how one describes a link as a set of VLANS

Case 2 - Between I2-NY and GEANT-Paris we want to create multiple GE circuits which can be used to create connections between I2 and GEANT. One way to do this seems to be to create a "traffic engineering-link" between NY and Paris. The GE Ports are used when making a connection, and the points of the link have to determine which ports are available in much the same way that we determine which VLANS are available now. This seems to me to be equivalent to creating a "virtual" link between NY and Paris.

I think Aaron said this would be possible (I may have misunderstood). If so I am wondering how this would be represented in the topology schema, and then how it is presented - presumably as a "view" or model to DCN.

So, the way I see this as being described would look similar to as follows: <network id="I2"> <!-- define a logical interface between NY and Paris --> <port id="I2_NY_to_GEANT-Paris"> <composed-of> <!-- include references to the actual physical ports --> <port id="I2_host1_eth0" /> <port id="I2_host2_eth1" /> </composed-of> </port> <!-- define the physical interface/link from host1 in NY to Paris --> <node id="I2_host1"> <port id="I2_host1_eth0"> <link id="I2_host1_eth0_link" /> <vlanAvailability>100-500</vlanAvailability> </port> </node> <!-- define the physical interface/link from host2 in NY to Paris --> <node id="I2_host2"> <port id="I2_host2_eth1"> <link id="I2_host2_eth1_link" /> <vlanAvailability>400-800</vlanAvailability> </port> </node> </network> Then the path finding could happen using the logical interface or by looking at the physical elements that can used to bring up the logical link for the logical interface. You could define a vlan link over a physical link similar to so using virtual ports: <node id="I2_host2"> <!-- the physical port --> <port id="I2_host2_eth1"> <link id="I2_host2_eth1_link" /> <vlanAvailability>400-800</vlanAvailability> </port> <!-- the vlan 'portion' of that port --> <port id="I2_host2_eth1.400"> <link id="I2_host2_eth1.400_link" /> <vlan>400</vlan> <over> <port id="I2_host2_eth1" /> </over> </port> </node> Another possibility would be to not have a virtual port and just include the new link under the physical port: <node id="I2_host2"> <port id="I2_host2_eth1"> <!-- the actual physical link --> <link id="I2_host2_eth1_link" /> <!-- the vlan link --> <link id="I2_host2_eth1_vlan400"> <vlan>400</vlan> </link> <vlanAvailability>400-800</vlanAvailability> </port> </node> I'm not sure which is the better way to do it. I like the virtual port concept because it is more consistent with how all other 'virtual' ports work (e.g. layer3 over layer2) and it allows us to easily describe the capabilities of that port like we would any other port (bandwidth, etc). It is, however, more verbose than just including the new link on the physical port. What does everyone else think? Cheers, Aaron

Freek Dijkstra wrote:

I strongly disagree with this ad-hoc solution:

...

<link id="I2_host2_eth1_link" /> <vlanAvailability>400-800</vlanAvailability>

Because: * the semantic is very technology specific. I rather see a more general model (in this case such as the label concept in GMPLS or multiplexing adaptation in G.805). * the syntax is very ad-hoc. The power of XML is that you can compose properties of object in detail. Why use regexp syntax like "400-800" instead of <range><min>400</min><max>800</max></range>

The focus of my example was more on clarity (single port vs. multiple port) than a specific set of requirements. In the more general model, there'd be a property that elements could have describing the possible sub-element that can be constructed. In this case, it would be the set of vlans. So, it might look like this: <sub-elements-options type="vlans"> <range>...</range> <range>...</range> <range>...</range> </sub-element-options> Sonet channels could look similar: <sub-elements-options type="sonetChannels"> <range>...</range> <range>...</range> <range>...</range> </sub-element-options> The sub-element-options might even be a better way of describing the possible choices for a virtual port since the specific one has not yet been selected: <network id="I2"> <!-- define a logical interface between NY and Paris --> <port id="I2_NY_to_GEANT-Paris"> <sub-element-options type="elementChoice"> <!-- include references to the actual physical ports --> <port id="I2_host1_eth0" /> <port id="I2_host2_eth1" /> </sub-element-options> </port> <!-- define the physical interface/link from host1 in NY to Paris --> <node id="I2_host1"> <port id="I2_host1_eth0"> <link id="I2_host1_eth0_link" /> </port> </node> <!-- define the physical interface/link from host2 in NY to Paris --> <node id="I2_host2"> <port id="I2_host2_eth1"> <link id="I2_host2_eth1_link" /> </port> </node> </network> Is this in line with what you were thinking? Cheers, Aaron

...

My question is how one describes a link as a set of VLANS

John, I'll write how we describe adaptations later. That first requires a discussion on what a "layer" is (an OSI layer, technology, or sublayer withing a technology). For now, please see e.g. the mail Jeroen sent to the list recently about how adaptations are done in ITU-T G.805.

...

Case 2 - Between I2-NY and GEANT-Paris we want to create multiple GE circuits which can be used to create connections between I2 and GEANT. One way to do this seems to be to create a "traffic engineering-link"

According to G.805, a link connection (= TE link above) can be made on a server layer by terminating a network connection on a client layer.

Either we simply want to describe that TE link, or we want to describe the terminated and adaptated network connection that creates the TE link. Possibly we want a model were we can do both. How exactly this is described is open. I guess we first need to discuss what a "path" is (I'd say G.805 tandem connection) and what a link is (I'd say G.805 link connection), and also what a layer is.

We haven't discussed these concepts so far. So feel free to step in and make suggestions about classes and relations.

Regards, Freek

_______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg

On Mar 27, 2008, at 11:25 AM, Aaron Brown wrote:

Things had gotten a bit quiet so I figure I should open up a can of worms :-) .

Freek Dijkstra wrote:

...

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.

If we mandate that *all* naming is completely context independent, then when given a random identifier, users are completely at a loss (since no context implies no domain information) as to where to get information on an element. If the only context it has is "this domain contains [uuid]", our schema can work like that except it adds a bit of extra information on it so you can type-check a given id. For example, if you didn't want any hierarchy below domain, you could just label everything like:

urn:ogf:network:domain=Internet2.edu:node=node1345 urn:ogf:network:domain=Internet2.edu:port=intf639 urn:ogf:network:domain=Internet2.edu:link=link23

My take on this is that all elements should have a meaningless, globally unique identifier with no hierarchical information in it at all. We do need human readable information but that can be pushed to other attributes or be inferred by relationships. An example interface: id = "1311477AD25" "interfaceName" => "TenGigabitEthernet1/1" How do we know which specific device it belongs to? Well, the device is a group so it'd look like: id = "98821CA88" "hostname" => "chic-sdn1.es.net" interfaces: 1311477AD25 .... And the domain is a group too, like: id = "12198DAC" "name" => "ESnet" devices: 98821CA88 .... Etc, etc. If our application needs to find out the "domain:device:interface" URN format for that interface, it can easily do that if it has the information above - and it can also easily resolve to the global identifier if it is given a urn- style "identifier". Advantage: if you are looking at just the Interface object you'll only be able to find stuff in the scope of the object itself, you won't get the network hierarchy or anything like that. This would help us have a nice and clean design with well-defined boundaries between objects. And, as a bonus, it'll make it easier to anonymize topology data; we can just push out ids and relationships rather than hierarchical names, and the mapping to the internal stuff would be trivial if we kept the same object ids. Disadvantage: It'll be a bit more cumbersome to look things up - users won't be able to just look at an id and immediately know stuff about it. But well, we'll have identifier lookup services and tools for that.

On Mar 27, 2008, at 2:22 PM, Aaron Brown wrote:

...

Disadvantage: It'll be a bit more cumbersome to look things up - users won't be able to just look at an id and immediately know stuff about it. But well, we'll have identifier lookup services and tools for that. The issue I have with meaningless, globally-unique names comes in constructing the lookup service. If we have one global lookup service, it's easy. If i want to know about a random id, i lookup

Evangelos Chaniotakis wrote: the id in that central service to find the authoritative topology service for that element, and then I go look up the element's information there. That centralized lookup service will have tremendous issues scaling, so we'd need to distribute the lookups. Since the IDs are completely random, to do that even somewhat feasibly, we'd have to use a DHT as the lookup service, and no matter what, every element in every domain would need to be in the DHT.

If we just did the "domain:uuid", each lookup service could keep the authoritative topology service for a given domain which would be an insignificant amount of information compared to having to know the authoritative topology service for every element in every domain. As soon as we define a semi-hierarchical identifier like that (and if administrators want to only define the semi-hierarchy, that's fine), we should think about how users might define a more strict hierarchy so if/when they do it, the approach will be standardized across domains.

That's a good point. Agreed. I think DNS is a good example to follow. As far as lookup is concerned, domains would be equivalent to DNS zones and referral etc could work the same way. And, of course, DNS has scaled pretty well.

Schoch wrote, back in 1978:

The 'name' of a resource indicates *what* we seek, an 'address' indicates *where* it is, and a 'route' tells us *how to get there*.

Amen! Aaron suggested:

urn:ogf:network:domain=Internet2:node=packrat:port=eth0

Jeroen suggested:

http://www.internet2.org/i2.rdf#packrat:eth0

The above examples both include *address* information in the *name*. The URN syntax defines a relation between port and node (eth0 is in packrat), and between node and domain (packrat is in Internet2). RDF defines a relation between name and lookup services (#packrat:eth0 can be looked up at http://www.internet2.org/i2.rdf). We should be careful not to enforce users to include all kinds of relationships in a name. I would advocate a transport protocol (or database specification) that not only transmit (defines) names of objects, but also the explicit relations between different objects. Regards, Freek

...

Aaron suggested:

...

urn:ogf:network:domain=Internet2:node=packrat:port=eth0

Jeroen suggested:

...

http://www.internet2.org/i2.rdf#packrat:eth0

The above examples both include *address* information in the *name*.

The URN syntax defines a relation between port and node (eth0 is in packrat), and between node and domain (packrat is in Internet2).

RDF defines a relation between name and lookup services (#packrat:eth0 can be looked up at http://www.internet2.org/i2.rdf).

Aaron replied:

NDL [mandates] that everything be defined in RDF files and that the identifiers contain pointers to the RDF files where the definitions occur.

We could do the same thing with a topology service URI: http://topology.internet2.edu:8080/perfSONAR_PS/services/topology#packrat:et.... If we did this, we'd be tying any external references (be they pathfinding, measurements, or whatever) to that specific instance of the definition. We'd not be able to move the topology service or split the data between multiple topology services or change the location of the RDF file without breaking external references.

Exactly my point. This name schema forces a relation between the *name* of an object and a lookup service, and if you move the lookup services, you are forced to rename (which is very inconvenient). I have the very same problem with the URN schema which says "urn:ogf:network:domain=Internet2:node=packrat:port=eth0". If I repatch a few devices or replace a broken node, I am forced to rename this identifier (which is very inconvenient). So again, I stress that I really like to see opaque identifiers for names. I dislike UUID as much as every other engineer, and as a human I rather see a more readable name. But as a programmer, and designer, I just don't want that name to have any semantical *meaning*. Now, thankfully there is a slight assertion error in your statement above:

NDL [mandates] that everything be defined in RDF files and that the identifiers contain pointers to the RDF files where the definitions occur.

First of all, NDL does not mandate that. Nowadays, some RDF gurus say that RDF does, but that is not in the original design. I could just as easily write in RDF: <Port id="urn:ogf:network:domain=Internet2:node=packrat:port=eth0"> <lookup-service>http://topology.internet2.edu:8080/perfSONAR_PS/services/topology</lookup-service> </Port>

Basically, this all comes down to (assuming I have this right), do we tie the identifiers to the location of the element's definition or do we tie the identifiers to a logical concept so that the identifiers are independent of the definition's location? And if the answer is both,

My preferred answer is none (don't tie identifier with anything) -- make it all explicit. For example, to make everything really explicit, you'll get: <Port identifier="urn:internet2.edu:UkRGIHN0aWxsIHJ1bGVzIQo"> <name>eth0</name> <lookup-service>http://topology.internet2.edu:8080/perfSONAR_PS/services/topology</lookup-service> <inDevice><ref identifier="urn:internet2.edu:UmVhbGx5IHNvCg"/></inDevice> <inDomain><ref identifier="urn:internet2.edu:a2lkZGluZy4uLgo"/></inDomain> </Port> <Node identifier="urn:internet2.edu:UmVhbGx5IHNvCg"> <name>packrat</name> </Node> <Domain identifier="urn:internet2.edu:a2lkZGluZy4uLgo"> <name>Internet2.edu</name> </Domain> Indeed, this is verbose. But you don't have to give out all information every time. Typically, a protocol should send the lookup service or domain information to a neighbour when it first mentions a port. With that, the neigbour can create its own local lookup table. So it's distributed and flexible. Regards, Freek

Aaron Brown wrote:

I'm thinking beyond simply path finding. What do we do when a user wants to get the status of all links along the circuit and check what's going on with the routers connecting those links? He's given back a list of identifiers for each link in the path of the form URN "urn:internet2.edu:UkRGIHN0aWxsIHJ1bGVzIQo". Who does he contact to find out where he can get monitoring information about that link let alone the routers?

Of course not. He is given a back a list of identifiers as well as a list of domains and services to contact for more information. Why not put it in the name than, you may ask. Well, for example because now a neighbour can later send an update ("hey, remember port urn:internet2.edu:UkRGIHN0aWxsIHJ1bGVzIQo? I already told you about the the lookup service. That is down now. Use <http....> in the future. And by the way, here is some more details about the bit error rates you requested."). In future years, protocol developers may want to build upon our ideas. Perhaps they figure that it is a good idea that a user first authenticates before it gets detailed information like domain or services. If we put that information in the name itself, they can't use our ideas anymore. On the other hand, if we make the relation explicit, we can handle such changes. Like you, I am also thinking beyond simply path finding. That's why I want to be so flexible.

Do we return the lookup service for each element every time?

Just the first time. Or after authentication. Or indeed, every time (after all, if you put that info in the name itself, you also give that information every time). Here comes the great part: we actually shouldn't define that. I think the goal of the NML-WG is not to dive in protocol and implementation details, like this. All we should do is come up with a good model, or ontology to describe networks. Regards, Freek

On Mar 28, 2008, at 8:39 AM, Freek Dijkstra wrote:

Here comes the great part: we actually shouldn't define that. I think the goal of the NML-WG is not to dive in protocol and implementation details, like this. All we should do is come up with a good model, or ontology to describe networks.

Doesn't a good model need to be usable for the use cases? (Most of the debate I have seen on the email list I think boils down to different people thinking about different use cases.) If you don't at least explore how identifiers remain globally unique, even in abstracted form how will you be sure your model actually works in practice? I"m not advocating one form over another here, but I do take issue with saying this is outside the scope of work. It would be a shame to spend a lot of time creating something that is not useful in the end. jeff -- Jeff W. Boote boote@internet2.edu

This is to contribute to the conversation about networks and abstraction. This is from the point of view of DCN and the need to do path computation at both the inter and intra network level. In my view the elements in a (interdomain) topology are nodes, links and networks (or domains). Nodes and links are pretty well understood, and are used for intradomain routing. Networks and links are used for interdomain routing, and it seems to me that often the attempt is to "abstract" networks as nodes so they use the same path finding as is used for nodes and links. There are problems with doing this, because networks are note nodes, and if abstracted to something other than what they are the abstract capabilities, with few exceptions, will be different than the real properties. For example if a network is abstracted as a single node, then there is no way to show different capacites between different edge points. If the network is abstracted as a mesh where every edge connect to every other edge, and there as a way to indicate bandwidth between edge points, then there is no way to show that some connections between edge points share the same internal path and so may block each other. In my mind it is good to consider network as a basic topological element. When doing interdomain routing, it is done between networks. One can use fully qualified links between networks, and can get these by "lifting" the interdomain links from the topology of each network. Routing between networks may need more policy or hints than routing within a domain, so it may be necessary to share properties of networks when routing between networks. I realize that this is very similar to creating an abstact view of a network, but I think it make it clearer what is being done, and it seems to me does is not harder and may be easier than creating abstract views. I am interested in what others think about this. John On Mar 5, 2008, at 9:32 PM, Aaron Brown wrote:

As I was writing the replay to Freek's question and getting my ideas clearly stated I diverged a bit from explicitly answering questions asked, so this is more of my general view of "how things should look" :-)

So, if a network is a subclass of node (thing with interfaces) and a network can also contain arbitrary network elements. How does one view a network as a node?

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>

A node in its most reasonable XML description looks like:

<node name="router1"> <port name="eth0" /> <port name="eth1" /> <port name="eth2" /> </node>

How would a network be described as both a node and a group so that it can be used in either context?

<network name="internet2"> <port name="host1_eth0" /> <port name="host2_eth0" /> <port name="host3_eth2" />

<comprised-of> <node name="host1> <port name="eth0" /> </node> <node name="host2> <port name="eth0" /> </node> <node name="host3> <port name="eth0" /> </node> </comprised-of> </network>

Now, let's say host 1, 2 and 3 were really providing the same logical service (say, host1 routes web service requests back to actual services on hosts 2 and 3). I want a logical view of this because i don't care how the web service is implemented. So, do I describe it as a network? a device? I'd say it's a logical node in our context.

<node name="logicalWebService"> <port name="host1_eth0" />

<service type="http" name="moodle" />

<comprised-of> <node name="host1> <port name="eth0" /> </node> <node name="host2> <port name="eth0" /> </node> <node name="host3> <port name="eth0" /> </node> </comprised-of> </node>

If one really wanted a more abstract view of the logical web service, you'd simply get rid of the comprised-of element:

<node name="logicalWebService"> <port name="host1_eth0" />

<service type="http" name="moodle" /> </node>

In the end, the full logical node definition looks (for all intents and purposes) identical to the network definition. Thus, I think the node concept lends itself nicely to a more general form of abstraction. To that end, is network really a special case? A network can be viewed as the abstract node by ignoring (or not including) the comprised-of portion. However, you can include those elements in it if so desired. Thus, whenever you're looking at a node-like element, there's a standard way of asking "what makes up this logical entity(domain, network, web service, whatever)?".

Going further, if you define a group like so:

<group name="something"> <comprised-of> ... network elements ... </comprised-of> </group>

Node looks to be a more specific version of group since it's a group of network elements (maybe none if you're at the atomic level of abstraction for a given topology element) that contains a set of external interfaces for that group of nodes.

As to the specific view/network model:

I think a view seems to be just be a restated group element. For example, let's say my topology includes the entire topology for 8 domains. Why can't I create a view that comprises elements in all 8 domains? (If, for example, I were creating a view that included all the PingER nodes that exist around the world).

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.

Other things to think about:

There are points between the domain is entirely opaque and the domain is entirely open:

All external nodes might be included in the description and might be connected via abstract links describing the logical connections between those points (I can get you bandwidth X across the domain if you exit via interface A and bandwidth Y if you exit via interface B). Does the "network as node" model work well for that case? In this case, you'd probably want to a network consisting of a set of abstract nodes connected via abstract links, but that shouldn't be too difficult to describe in this model.

I figure I'll stop typing now since I've already taken up far too much of your time ;)

Cheers, Aaron _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg

John Vollbrecht, Senior Network Engineer Internet2 office +1-734-352-4960 | mobile +1-734-395-7890

Freek Dijkstra wrote:

Evangelos Chaniotakis wrote:

...

I'm on the fence as to whether we need a separate "network" concept. We might need to model administrative domains that run multiple independent networks.

You totally convinced me. So:

DOMAIN = administrative domain = an organisational entity that is responsible for the operational control of resources (including network resources)

NETWORK = a collection of network elements that behaves as a single resource (it is possible to describe the functionality without exposing the internal implementation or detailed internal limitations)

I don't know how to describe VIEW. Evangelos, Aurélien, do you have suggestions?

I would say that a Network is a collection of Views, and a View is a collection of Network Elements. I don't think either "behaves like a single resource" but maybe we're thinking of different things. <snip>

Shouldn't that be:

- Domain --- Network ----- View (type = "monitoring") -------- Network Element -------- Network Element ---------- Network Element -------- .... ----- View (type = "controlplane") -------- Network Element -------- Network Element -------- .... ----- View (type = "export") -------- Network Element ---------- Network Element -------- Network Element -------- .... --- Network ------ ....

A few questions about your tree. * May a single network element occur in multiple views (I assume so) Yes. * Must a network element be part of only one domain (I assume so) I would say yes. Although there's certainly some real-world scenarios where multiple administrative domains share some infrastructure, I don't

Well, I was still on the fence about the Network element, that's why I didn't include it there. But I agree with the above; I think we should have Views under Network. think we should model this.

* Can a view consist of network elements in multiple domains? (I really don't know about this one, but if true, a view can also be higher in the tree than a network)

I would say no. It's certainly conceivable, but let's keep Views under Network.

Given your tree, am I correct to assume these relations: domain:network = 1:many (each network is under control of only one domain) network:view = 1:many (a view can only contain network elements within a single domain) network element:view = many:many (a network element can occur in multiple views) network element:network = many:1 (a network element can only be part of one network) This looks right to me.

Evangelos Chaniotakis wrote:

...

Can we call them "Views" instead of "Models"? "Model" is a quite overloaded word, especially in a semantic context.

Aurélien Cedeyn wrote:

I tortured myself to find the good word to represent what i mean. First i used the term of "View" but view implies that a description is already here.

I like "view". But perhaps simply "network" (not to be confused with administrative domain) or just "group" (or "group_of_network_elements"). Just as long as the relational properties are clear, I don't mind calling it "EckyEckyEckyEckyPikangZoomBoing". Freek