... quick update (just to be as close as possible to MDM RRD MA) Roman W dniu 2012-07-13 13:58, Roman Łapacz pisze:

Thanks Freek. Your changes look very good.

I attached an example of RRD MA metadata file with two metadata elements (I removed vlan info as it is not used by the service). I don't think existing pS services have to use NML in near future but it's valuable to present how this could look like (prove that NML fits).

Roman

W dniu 2012-07-12 16:36, Freek Dijkstra pisze:

...

On 12-07-2012 15:58, Roman Łapacz wrote:

...

Hi,

I'm thinking how NML could be used in existing pS services, especially in RRD MA.

See below. Any suggestions/comments how this could be done?

metadata piece valid for RRD MA:

<nmwg:metadata id="meta1"> <netutil:subject id="subj1"> <nmwgt:interface> <nmwgt:hostName>test-hostName</nmwgt:hostName> <nmwgt:ifAddress type="ipv4">10.1.2.3</nmwgt:ifAddress> <nmwgt:ifName>test-0</nmwgt:ifName> <nmwgt:ifDescription>test descripyion</nmwgt:ifDescription> <nmwgt:direction>in</nmwgt:direction> <nmwgt:capacity>1000BaseT</nmwgt:capacity> </nmwgt:interface> </netutil:subject> <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType> <nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType> <nmwg:parameters id="params1"> <nmwg:parameter name="keyword">project:geant2</nmwg:parameter> </nmwg:parameters> </nmwg:metadata>

a quick proposal using NML's Port that looks strange to me:

<nmwg:metadata id="meta1"> <netutil:subject id="subj1"> <nml:Port> <nml:label labelType="http://schemas.ogf.org/nml/ip/ipv4/if/address/2013/10/">193.10.252.66</nml:label> <nml:label labelType="http://schemas.ogf.org/nml/ip/ipv4/if/hostNames/2013/10/">test-hostName</nml:label>

... ... ... </nml:Port> </netutil:subject> <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType> <nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType> <nmwg:parameters id="params1"> <nmwg:parameter name="keyword">project:geant2</nmwg:parameter> </nmwg:parameters> </nmwg:metadata> First two comments,

1. I don't think the above are labels. GMPLS and G.800 have a very specific meaning with the term "label". G.800 defines:

...

"A label provides a means of providing added information for the purpose of distinguishing and identifying individual communications within a communication which is formed to convey a combination of communications" After taking some aspirin I take this to mean "A label is the information that distinguishing individual data stream within a larger data stream". So a VLAN ID in 802.1Q Ethernet, the wavelength in DWDM, the VCI in ATM, or the timeslot in SDH. The hostname is not a label.

2. The URIs look a bit odd to me. GFD.084 would probably use something along the lines of http://schemas.ogf.org/nml/2013/10/dns/hostName, -or with Jason suggestion to move the date further to the back- http://schemas.ogf.org/nml/dns/2013/10/hostName

Now onto the solution. I think that the single strength of NML is that it allows a place to describe all sorts of properties of the network, so all a monitoring system no longer need to provide that information itself, but only need to point to it. So we can rip out all of the<nmwgt:interface> part from the monitoring service, and replace it with a simple (URN) pointer to the (NML) Port, which is described in detail in NML.

I presume the combination of the two looks something like this: (copied as quotation to stop my mailer from wrapping lines)

...

<!-- NML Topology -->

<nml:Node id="urn:ogf:network:netherlight.net:2010:Asd001a-ome24"> <nml:name>test-hostName</nml:name> <nml:Relation type="http://schemas.ogf.org/nml/base/2013/10/hasInboundPort"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:vlan110:in" /> </nml:Relation> </nml:Node>

<nml:Port id="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:vlan120:in"> <nml:name>test-0</nml:name> <nmwgt:description>test description</nmwgt:description> <nml:label encoding="http://schemas.ogf.org/nml/ethernet/2013/10/vlan">120</nml:label> <nmleth:capacity>1000BaseT</nmleth:capacity> <nmlip:ipv4address>10.1.2.3</nmlip:ipv4address> </nml:Port>

<!-- Monitoring Data -->

<nmwg:metadata id="meta1"> <netutil:subject id="subj1"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:vlan120:in"/> </netutil:subject> <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType> <nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType> <nmwg:parameters id="params1"> <nmwg:parameter name="keyword">project:geant2</nmwg:parameter> </nmwg:parameters> </nmwg:metadata>

<nmwg:data metadataIdRef="meta1" id="data.6343912">> <nmwg:datum timeType="unix" value="0.302" valueUnits="float" timeValue="1320605686"/> <nmwg:datum timeType="unix" value="0.821" valueUnits="float" timeValue="1320605687"/> <nmwg:datum timeType="unix" value="0.365" valueUnits="float" timeValue="1320605688"/> <nmwg:datum timeType="unix" value="0.724" valueUnits="float" timeValue="1320605689"/> </nmwg:data> Regards, Freek

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

W dniu 2012-07-13 14:48, Fausto Vetter pisze:

Hi Roman,

Hi Fausto,

In case of pS, wouldn't be usedful to have a representation of the interface as bidirectional?

It is possible to group unidirectional nml:Ports and have nml:BidirectionalPort an example: <nml:BidirectionalPort id="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9"> <nml:Port idRef="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9-out"> <nml:Port idRef="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9-in"> </nml:BidirectionalPort>

I have seen some mentioning to this possibility in NML. I miss a parameter to say the direction that the data is representing (parsing IDs for that is not a clear way).

Right, in this example the direction is indicated in URN. I think nml:direction inside Port wouldn't be a bad idea. Freek, what do you think?

Also, I have seen that event types are in data and metadata, couldn't it be removed in one of the elements?

Key inside data depends on an implementation. It's not a part of pS standard. An implementation knows how to use it (even it may be treated as a unique string; in MDM RRD MA it is interpreted in a specific way). Roman

Regards, Fausto Vetter

Diretoria de Pesquisa & Desenvolvimento (DPD) / Research & Development Department Gerência de Redes para Experimentos (GRE) / Management of Network for Experiments RNP – Rede Nacional de Ensino e Pesquisa http://www.rnp.br Telefone: +55 (21) 2102 9696 E-mail: fausto.vetter@rnp.br

------------------------------------------------------------------------ *De: *"Roman Łapacz" <romradz@man.poznan.pl> *Para: *nml-wg@ogf.org *Enviadas: *Sexta-feira, 13 de Julho de 2012 9:07:14 *Assunto: *Re: [Nml-wg] nmwgt -> nml

... quick update (just to be as close as possible to MDM RRD MA)

Roman

W dniu 2012-07-13 13:58, Roman Łapacz pisze:

Thanks Freek. Your changes look very good.

I attached an example of RRD MA metadata file with two metadata elements (I removed vlan info as it is not used by the service). I don't think existing pS services have to use NML in near future but it's valuable to present how this could look like (prove that NML fits).

Roman

W dniu 2012-07-12 16:36, Freek Dijkstra pisze:

On 12-07-2012 15:58, Roman Łapacz wrote:

Hi,

I'm thinking how NML could be used in existing pS services, especially in RRD MA.

See below. Any suggestions/comments how this could be done?

metadata piece valid for RRD MA:

<nmwg:metadata id="meta1"> <netutil:subject id="subj1"> <nmwgt:interface> <nmwgt:hostName>test-hostName</nmwgt:hostName> <nmwgt:ifAddress type="ipv4">10.1.2.3</nmwgt:ifAddress> <nmwgt:ifName>test-0</nmwgt:ifName> <nmwgt:ifDescription>test descripyion</nmwgt:ifDescription> <nmwgt:direction>in</nmwgt:direction> <nmwgt:capacity>1000BaseT</nmwgt:capacity> </nmwgt:interface> </netutil:subject> <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType> <nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType> <nmwg:parameters id="params1"> <nmwg:parameter name="keyword">project:geant2</nmwg:parameter> </nmwg:parameters> </nmwg:metadata>

a quick proposal using NML's Port that looks strange to me:

<nmwg:metadata id="meta1"> <netutil:subject id="subj1"> <nml:Port> <nml:label labelType="http://schemas.ogf.org/nml/ip/ipv4/if/address/2013/10/">193.10.252.66</nml:label> <nml:label labelType="http://schemas.ogf.org/nml/ip/ipv4/if/hostNames/2013/10/">test-hostName</nml:label>

... ... ... </nml:Port> </netutil:subject> <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType> <nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType> <nmwg:parameters id="params1"> <nmwg:parameter name="keyword">project:geant2</nmwg:parameter> </nmwg:parameters> </nmwg:metadata>

First two comments,

1. I don't think the above are labels. GMPLS and G.800 have a very specific meaning with the term "label". G.800 defines:

"A label provides a means of providing added information for the purpose of distinguishing and identifying individual communications within a communication which is formed to convey a combination of communications"

After taking some aspirin I take this to mean "A label is the information that distinguishing individual data stream within a larger data stream". So a VLAN ID in 802.1Q Ethernet, the wavelength in DWDM, the VCI in ATM, or the timeslot in SDH. The hostname is not a label.

2. The URIs look a bit odd to me. GFD.084 would probably use something along the lines of http://schemas.ogf.org/nml/2013/10/dns/hostName, -or with Jason suggestion to move the date further to the back- http://schemas.ogf.org/nml/dns/2013/10/hostName

Now onto the solution. I think that the single strength of NML is that it allows a place to describe all sorts of properties of the network, so all a monitoring system no longer need to provide that information itself, but only need to point to it. So we can rip out all of the<nmwgt:interface> part from the monitoring service, and replace it with a simple (URN) pointer to the (NML) Port, which is described in detail in NML.

I presume the combination of the two looks something like this: (copied as quotation to stop my mailer from wrapping lines)

<!-- NML Topology -->

<nml:Node id="urn:ogf:network:netherlight.net:2010:Asd001a-ome24"> <nml:name>test-hostName</nml:name> <nml:Relation type="http://schemas.ogf.org/nml/base/2013/10/hasInboundPort">

<nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:vlan110:in" /> </nml:Relation> </nml:Node>

<nml:Port id="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:vlan120:in"> <nml:name>test-0</nml:name> <nmwgt:description>test description</nmwgt:description> <nml:label encoding="http://schemas.ogf.org/nml/ethernet/2013/10/vlan">120</nml:label> <nmleth:capacity>1000BaseT</nmleth:capacity> <nmlip:ipv4address>10.1.2.3</nmlip:ipv4address> </nml:Port>

<!-- Monitoring Data -->

<nmwg:metadata id="meta1"> <netutil:subject id="subj1"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:vlan120:in"/> </netutil:subject> <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType> <nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType> <nmwg:parameters id="params1"> <nmwg:parameter name="keyword">project:geant2</nmwg:parameter> </nmwg:parameters> </nmwg:metadata>

<nmwg:data metadataIdRef="meta1" id="data.6343912">> <nmwg:datum timeType="unix" value="0.302" valueUnits="float" timeValue="1320605686"/> <nmwg:datum timeType="unix" value="0.821" valueUnits="float" timeValue="1320605687"/> <nmwg:datum timeType="unix" value="0.365" valueUnits="float" timeValue="1320605688"/> <nmwg:datum timeType="unix" value="0.724" valueUnits="float" timeValue="1320605689"/> </nmwg:data>

Regards, Freek

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

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

Hi, On 13-07-2012 15:11, Roman Łapacz wrote:

...

In case of pS, wouldn't be usedful to have a representation of the interface as bidirectional?

It is possible to group unidirectional nml:Ports and have nml:BidirectionalPort

an example:

<nml:BidirectionalPort id="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9"> <nml:Port idRef="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9-out"> <nml:Port idRef="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9-in"> </nml:BidirectionalPort>

In case of these ps measurements I would even argue that it is useful to have directed ports. The example is about bandwidth utilization, which is really a measurement in one specific direction. FV: True, but the measurement itself woudl be related to the nml:Port , but the node could be related to the BidirectionalPort (as a router/switches has physical interfaces that at the same time allows in and out traffic. As Roman correctly pointed out, it is possible to associate both directed Ports together, so you can programmatically find the two RRD files and put them in the same graph. FV: How would you do that without a BidirectionalPort? Parsing IDs? I think it would look more robust to have the BidirectionalPort representation and have the nodes composed of BidirectionalPort's. Actually, nearly all measurements (perhaps with the exception of RTT) are really in one direction. Think about port up/down status, bandwidth utilization, one-way delay, ... FV: Indeed.

...

I have seen some mentioning to this possibility in NML. I miss a parameter to say the direction that the data is representing (parsing IDs for that is not a clear way).

Right, in this example the direction is indicated in URN. I think nml:direction inside Port wouldn't be a bad idea. Freek, what do you think?

In this case, the direction is indicated by the relation between the node and the port:

<nml:Node id="urn:ogf:network:netherlight.net:2010:Asd001a-ome24"> <nml:name>test-hostName</nml:name> <nml:Relation type="http://schemas.ogf.org/nml/base/2013/10/hasInboudPort"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:in" /> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/base/2013/10/hasOutboubdPort"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:out" /> </nml:Relation> </nml:Node>

FV: Indeed, but if you start having several Port elements for each direction, how would you represent the bidirection for a single interface? ID parsing? (PS: I see two typos here :) ). Regards, Fausto Vetter Diretoria de Pesquisa & Desenvolvimento (DPD) / Research & Development Department Gerência de Redes para Experimentos (GRE) / Management of Network for Experiments RNP – Rede Nacional de Ensino e Pesquisa http://www.rnp.br Telefone: +55 (21) 2102 9696 E-mail: fausto.vetter@rnp.br

Hi,

...

...

In case of pS, wouldn't be usedful to have a representation of the interface as bidirectional?

It is possible to group unidirectional nml:Ports and have nml:BidirectionalPort

an example:

<nml:BidirectionalPort id="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9"> <nml:Port idRef="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9-out"> <nml:Port idRef="urn:ogf:network:domainx.net:2012:A:port_ge-0.2.9-in"> </nml:BidirectionalPort>

In case of these ps measurements I would even argue that it is useful to have directed ports. The example is about bandwidth utilization, which is really a measurement in one specific direction.

the node could be related to the BidirectionalPort (as a router/switches has physical interfaces that at the same time allows in and out traffic.

Currently, in NML the nml:Node is related to (unidirectional) nml:Ports, and two nml:Ports can be related to a nml:BidirectionalPort. The reason for this is that it unambiguously encodes the direction of each Port. Note that nml:Ports represent logical datatransports, so it's not necessary a physical interface of a router or switch. I once asked how useful it would be to represent a physical interface, but making that explicit relation was considered unneeded, as NML is mostly used in a multi-domain environment, thus for exchanging topology info between domain, and in that scenario you are likely to describe the function rather than the implementation of that function at specific devices. That hasn't prevented people from assigning nml:Port identifiers to physical interfaces. I'm very interested to hear about practical use cases where such distinction is relevant and how you like to relate the different elements. FV: I am kind of following you know.

As Roman correctly pointed out, it is possible to associate both directed Ports together, so you can programmatically find the two RRD files and put them in the same graph.

FV: How would you do that without a BidirectionalPort? Parsing IDs? I think it would look more robust to have the BidirectionalPort representation and have the nodes composed of BidirectionalPort's.

No, parsing IDs is kind of "not done" (as it would imply adding attributes to an identifier, which is problematic if those attributes change. Got a long discussion with some URN zealots on this, and fear they brainwashed me too ;) ). A Node is related to (unidirectional) Ports using the "hasInboundPort" and "hasOutboundPort" relations. If a node has such a relation with two of Ports, and these two Ports are grouped as a BidirectionalPort, then you can say that the Node contains this BidirectionalPort. FV: Fine, I am following you now.

In this case, the direction is indicated by the relation between the node and the port:

...

<nml:Node id="urn:ogf:network:netherlight.net:2010:Asd001a-ome24"> <nml:name>test-hostName</nml:name> <nml:Relation type="http://schemas.ogf.org/nml/base/2013/10/hasInboudPort"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:in" /> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/base/2013/10/hasOutboubdPort"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:out" /> </nml:Relation> </nml:Node>

FV: Indeed, but if you start having several Port elements for each direction, how would you represent the bidirection for a single interface? ID parsing?

Combine the two XML examples, so you have all four relations Node --hasOutboundPort--> Port 1 --hasInboundPort--> Port 2 BidirectionalPort Port 1 Port 2 Or: Node --hasOutboundPort--> Port 1 --hasInboundPort--> Port 2 BidirectionalPort Port 1 Port 2 We are aware that this is not ideal XML, but an unfortunate consequence that our UML schema is not fully hierarchical, and contains circular relations (such as in this common case), which we can only describe in XML using the id/idRefs. Here is the full XML:

<nml:Node id="urn:ogf:network:netherlight.net:2010:Asd001a-ome24"> <nml:name>test-hostName</nml:name> <nml:Relation type="http://schemas.ogf.org/nml/base/2013/10/hasInboudPort"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:in" /> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/base/2013/10/hasOutboubdPort"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:out" /> </nml:Relation> </nml:Node> <nml:BidirectionalPort id="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:in"> <nml:Port idRef="urn:ogf:network:netherlight.net:2010:Asd001a-ome24:1-5-4:out"> </nml:BidirectionalPort>

FV: Fine, I am following you now. Thanks, Fausto Vetter Diretoria de Pesquisa & Desenvolvimento (DPD) / Research & Development Department Gerência de Redes para Experimentos (GRE) / Management of Network for Experiments RNP – Rede Nacional de Ensino e Pesquisa http://www.rnp.br Telefone: +55 (21) 2102 9696 E-mail: fausto.vetter@rnp.br