August 2013 - nml-wg - lists.ogf.org

Adding an attribute
by Jeroen van der Ham 02 Sep '13

02 Sep '13

Hi, I realised today that I never included a definition for URL references in the topology definition. We have had a discussion about this in the NML group, and it was decided that this is a control-plan construct and would not be added to NML. So, for the NSI extension I am proposing to add an attribute to Network Object "isReference" which has a URI as value which points to a topology file that contains more information on that object. This attribute would be defined in the NSI extension schema. Now, if everyone agrees, I have a practical question: how do I express this in the XML Schema? The schemas are available here: https://github.com/jeroenh/NSI-Topology/tree/master/schemas Jeroen.

2 2

Postdoc position at the SNE group, UvA
by Jeroen van der Ham 27 Aug '13

27 Aug '13

Hi all, At the SNE group we have an open position for a post-doc in the area of networking and topology description research. See also http://www.uva.nl/over-de-uva/werken-bij-de-uva/vacatures/item/13-267.html Note, the application deadline is September 6th. Jeroen.

1 0

Re: [Nml-wg] [Nsi-wg] Tutorial Topologies
by Freek Dijkstra 16 Aug '13

16 Aug '13

Hi Chin, Sorry for not responding sooner. Off-list, you brought up the following issue. I hope it is OK to quote you on-list. You brought up an important issue. >> Thanks for sending out the topologies. >> >> I tried importing them into the topology service that Ahmed >> implemented (at http://lstest.es.net) but ran a couple of issues, one >> small, and the other a bit more involved. >> [...] >> As for the more involved issue, our parser is unable to distinguish >> between what is a reference, and what is not, so for example: >> >> Excerpt from aruba.xml: >>  >> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort"> >> <nml:PortGroup id="urn:ogf:network:aruba.example:2013:aruba-bonaire"> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2012/10/ethernet#vlan">1780-1783</nml:LabelGroup> >> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> >> <nml:PortGroup id="urn:ogf:network:bonaire.example:2013:aruba-bonaire"/> >> </nml:Relation> >> </nml:PortGroup> >> </nml:Relation> >> >> Excerpt from bonaire.xml: >>  >> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> >> <nml:PortGroup id="urn:ogf:network:bonaire.example:2013:aruba-bonaire"> >> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2012/10/ethernet#vlan">1780-1783</nml:LabelGroup> >> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> >> <nml:PortGroup id="urn:ogf:network:aruba.example:2013:aruba-bonaire"/> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> </nml:Relation> >> </nml:PortGroup> >> </nml:Relation> >> >> After we import the aruba.xml topology into the topology server, when >> we import bonaire.xml, our server doesn't know Bonaire's aliased >> "aruba-bonarie" port group is a reference, and overwrites Aruba's entry. This very issue is covered in section 4.3 of GFD.206. This is a verbatim quote of that section: > 4.3 Combining Object Descriptions > > A given object may have multiple attributes and relations. These > attributes and relations may be described in different places in a > syntax. It is up to the parser to combine all attributes and > relations. > > NML currently does not have a mechanism to check if a given > description of an object is complete. Thus, it does not distinguish > between a full description of an object or merely a pointer to an > object. > > Parsers should be aware that the NML descriptions do not provide any > guarantee regarding the integrity nor the authenticity of the > description. Parsers are advised to use external mechanism to avoid > that an erroneous description of an object in one (possibly > malicious) topology description pollutes a correct description of the > same object in another topology description. So basically, the idea is that the second (reference) description does not overwrite the original description, but augments it, combining the two. Either solution (replacing or augmenting a description) raises some security issues, in that an attacker may add false descriptions of STP, in order to insert malicious information in the topology. For that reason, it is highly recommended that NSI implementations take the source of information into account, and are very selective in accepting information from a domain, that describes information about another topology. I believe NSI has some mechanisms to In fact, the whole isAlias construct is made specifically to make it easier to reference between sources of information. So my recommendation is not to accept any information about a STP or Port, from another domain, except as the destination of an "isAlias" relation. >> I had a couple of thoughts on this, but they may be a complete hack >> and ugly. >> >> 1. If an "empty" element (that has no further nested elements, e.g. >> Bonaire's "aruba-bonarie" port group) matches an existing "non-empty" >> element (e.g. Aruba's "aruba-bonarie" port group), it is assumed to be >> a reference. This might make things like modify complicated, but >> maybe if we can make the assumption that only "non-empty" elements can >> modify existing elements, that might work. >> >> 2. Use the "isAlias" relation to assume referencing. This will only >> be specific to NML/NSI, but then it may be acceptable compromise. The second one is true for all relations: <nml:SomeObject id="A"> <nml:Relation type="http://....#someRelation"> <nml:OtherObject id="B"> In this case, A the _source_ and B is the _domain_ of the relation. B is always a reference. This object B can contain some more information, but I strongly recommend to be careful to accept any information from any source other than the domain. (judged by the nsi:managedBy relation from topology to NSA). Hope this helps! Freek -- SURFsara has a new telephone number: + 31 20 800 1300. Freek Dijkstra | Group Leader | Network Innovation & Support | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 20 800 1320 | | Freek.Dijkstra(a)surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Thu | Fri |

1 0

Transition!
by Jeroen van der Ham 15 Aug '13

15 Aug '13

Hi all, After about 10 years of research in network topology descriptions and related areas, I feel it is time for some change :) As of September 1st I will be moving to a new job. But don't worry, I will not be going very far away: I will be moving to the education side and will be teaching at the System and Network Engineering Master at the UvA. In that position I will also have one day a week available for research, which at the start will be used to make sure that the transition goes as smoothly as possible. I will still be attending the GLIF and NSI meetings in Singapore, but after that it is far less likely I will be able to travel or contribute to meetings. It has really been a pleasure and privilege to work in these great communities and to have been able to (heatedly ;)) discuss ideas with international peers. You have all made me feel very welcome and every meeting of GLIF and OGF has always been a very enjoyable experience. I will certainly miss the friendly dinners in remote locations :). Some of my responsibilities will be taken over by Paola Grosso while the research group looks for a new post-doc. If you have any questions, feel free to contact me. Thank you all, Jeroen van der Ham.

1 0