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: <!-- Aruba - Bonaire --> <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: <!-- bonaire - aruba --> <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@surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Thu | Fri |