W dniu 2012-03-12 20:54, Jason Zurawski pisze:
Hi Freek/All;
On 3/12/12 1:15 PM, thus spake Freek Dijkstra:
Jason Zurawski wrote:
I am attaching my commentary as a text file. I will note that this is a *lot* of information to process at a single time (which is frustrating), and your examples are spread over multiple files (with references within each file, also frustrating). Commentary became very challenging in this format, A better collaboration method will be needed I fear ...
It is indeed a lot to process, thank you very much for going through it. I tried to stick to a single topic within a file, and list alternatives within that same file.
I wanted to finish it because I know it was challenging, and I only had this week I have time to explain in person to some group members. I also anticipated that I would have to do some more explaining next weeks, so I'm thoroughly impressed that you found time to look through it on such short notice. Kudos.
Given that, here is a quick executive summary:
- The concept of the alias topo is not very foreign (and a private topo that can related to some other is a good thing to care about), but I fear that we are trying to do 'too much' at the schema level here. Private topos can be protected at a higher layer from being shared. Because of this, I would claim that a public/private topo are both at the same 'level', and can be related, and shouldn't be defined within each other.
I'm currently only concerned *that* they can be related, similar how a node can be related to a topology. I agree that they don't have to be defined within each other, and am fine if they simply refer to each other. It should be perfectly fine to either:
* Specify a topology with all details. * Specify a topology without specifying details, leaving out internal subtopologies, Nodes, etc. * Specify a topology with some details, e.g. giving a hasTopology relation and using a idRef, thus without the details of the subtopology
This all sounds fine to me.
Because of this, I would claim that a public/private topo are both at the same 'level', and can be related, and shouldn't be defined within each other.
Do you mean same XML 'level'? e.g.:
<nml:Topology id="aaaaaaa"> <nml:Relation type="hasSubtopology"> <nml:Topology idRef="urn:ogf:network:a.net:subtopo"/> </nml:Relation> ... </nml:Topology> <nml:Topology id="urn:ogf:network:a.net:subtopo"> ... </nml:Topology>
Yes, basically have them be defined independently and linked later as you note here. 2 quick use cases:
Can we say that we may have two options of joining the topologies: 1) horizontally (the same layer) and 2) vertically (different layers) example for 1) <nml:toplogy id="urn:ogf:network:a.net:topoX""> <nm:relation type="merge"> <nml:toplogy idRef="urn:ogf:network:a.net:topoY"/> </nm:relation> </nml:topology> I use the word "merge" but it could be something different. example for 2) <nml:toplogy id="urn:ogf:network:a.net:topoX""> <nm:relation type="adaptation"> <nml:toplogy idRef="urn:ogf:network:a.net:subtopoX"/> </nm:relation> </nml:topology> I hope I understand "adaptation" the right way (again, this could be a different name). This relation type could be used each time we want to have sub-layers (for example, also for ports or links). It would be up to a user/application which topology element/container is shared. Roman
- Internet2 network topology, and then the sub topology for ION and NDDI, which are both 'owned' by Internet2 and use the same footprint. These may all live in the same service, and probably wont be defined at the same time (although they could be).
- Internet2 NDDI topology, and then an experimental openflow topology defined by some experiment external to Internet2 (e.g. GENI). It will be the case these live in different services.
- Defining first order elements in relations is problematic for referencing them elsewhere (even if they are meant to be private). We need to be careful about this
I'm sorry, I don't understand this. Does "first order elements" mean "root XML elements" or "direct child elements"?
Do we perhaps have a different view on the use of nml:Topology? For me it is just a Network Object, kind of similar to a Node (in that it has Ports, and a name). nml:Topology does not have to be the root XML element (though I think it usually will be, even if it is for referencing purposes).
I am thinking of situations like this:
<topo id=1> <relation> <topo id=2> <!-- all of the info on this --> </topo> </relation> </topo>
<topo id=3> <relation> <!-- just a reference --> <topo id=2 /> </relation> </topo>
Unless we exhaustively unrolled the fact that the topo #2 was defined inside of a relation in another topo (#1), its hard for #3 to make a reference to it. Does this help?