[Nml-wg] XML Examples and Proposals

[Roman Łapacz]

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?