| |
Comment: |
Attaching comments from email list traffic:
Jason:
>> - 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.
Freek:
> 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
Jason:
This all sounds fine to me.
-----------
Jason:
>> 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.
Freek:
> 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>
Jason:
Yes, basically have them be defined independently and linked later as you note here. 2 quick use cases:
- 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.
-----------
Jason:
>> - 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
Freek:
> 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).
Jason:
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?
|
