[Nml-wg] XML Examples and Proposals

[Jerry Sobieski]

Hi guys-

Before any decisions are made by NML group about NSI concepts, I would 
like to have a more time to understand the of detail these various 
issues - some seem pretty obvious, but others seem to be reference some 
prior discussions.   Also, I present the NSI/NML proposal to NSI group 
tomorrow for discussion.  (FYI - If I undetand what is proposed below, I 
don't think there are issues...I just want to make sure it says what I 
think..:-)

Freek- perhaps you and I could have another chat in the next couple days 
here?   There are only a few things I want to understand in great detail 
- and these have to do with how the NSI concepts function within the 
integrated model.   I am less concerned about what they are called 
(nodes vs topologies, aliases, etc.)  as long as we have a clear 
functional model that is consistent with NSI, and we understand how we 
define the nested topology relations, and feather these imperceptably 
into the other NML objects or constructs.   We have to understand how 
NSI agents will explore the database using the proposed relations to 
find the objects they need.

Lets chat Tuesday at the venue Freek and find same face time?
Thanks
Jerry

On 3/12/12 4:54 PM, Jason Zurawski wrote:
> 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:
>
>  - 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?
>
>>
>>>    - Some things have an explicit parent/child relationship already 
>>> (e.g.
>>> we know a topology contains nodes, ports, links).  Using a relationship
>>> to say 'hasNodes' or something similar is redundant, we know they are
>>> involved with the topology due to the nature of the schema.
>>
>> Agreed that it is not necessary. I did it for consistency. E.g. if
>> Topology ->  Topology, Node ->  Port, Node ->  Service are all explicit
>> (hasTopology, hasPort/hasOutboundPort, hasService), it makes sense to
>> also use hasNode. Or we define some others redundant too. (e.g. a
>> Service in a Node always implies hasService, a Topology in a Topology
>> always implies a hasTopology, etc.)
>
> This really bashes the argument of needing a well defined schema 
> though.  If everything is related to other things via relationships 
> (and we never use the explicit parent/child), we end up with this:
>
>  - Node, Port, Topology, Link, etc. etc. don't contain anything except 
> relationships
>
>  - Relationships allow 'any element' to be inside
>
>  - 'Rules' are all semantic for each relationship type
>
>  - schematic checking is useless
>
> Wasn't it you who argued a couple of months ago that we need well 
> defined schema so that we know what each element can/may contain :) ?
>
> I agree with your line of reasoning that is hast to be consistent in 
> our use of parent/child vs relationships, and this was a minor mistake 
> on my examples from Sept as I read them now.
>
> At least in my mind, I would *like* to interpretation the relationship 
> for logical or fuzzy concepts:
>
>  - Serial compound pushes together two links
>
>  - two ports are pushed together into a bidirectional
>
>  - a switching service has inbound and outbound ports associated with it
>
>  - a link needs to describe the in vs out ports
>
> I would claim that we don't need these in a relation, and this may 
> force some example changes:
>
>  - a switch won't need 'hasports' by itself sine we know the switch 
> has the ports via parent/child.
>
>  - A switch can have 'hasinbound' or 'hasoutbound' port relations, as 
> this adds more value
>
>  - A topology with 'hasnodes' doesn't seem necessary, we know it has 
> nodes (and ports and links).
>
>  - A node with 'providesService', the service could be a direct 
> parent/child (unless its special maybe, I dont have a good use case)
>
> I could be wrong of course, but this seems to make sense as I type it. 
> We should try to use explicit things when we can.
>
>>>    - I see no benefit to the 'version' concept over 'lifetime', in 
>>> fact i
>>> believe it limits us more.  Your use of lifetime (as a relation) is not
>>> really correct.  Aaron should provide you with examples of how we use
>>> this as a first order element.
>>
>> I came to realise that lifetime and version are two different concepts.
>>
>> A lifetime signifies a duration (e.g. of a reserved link), while a
>> version is a sequence number to track updates of a 'document' (where
>> 'document' is a network description).
>
> then why not use the versioned namespace?  Thats why we put versions 
> in namespaces?
>
> <nml1:topo />
>
> <nml2:topo />
>
> Where these prefixes are slightly different namespaces.  Perhaps I am 
> missing the distinction ...
>
> Thanks;
>
> -jason
>
>> Comparing them side-by-side was probably a mistake of mine, that could
>> have lead to misunderstanding, chaos and the downfall of civilisation.
>>
>>
>>>    - Lifetimes (or versions) should be associated with a 1st order
>>> element in my opinion, not a relation (which is an action of an 
>>> element,
>>> and not a first order element).  This is a bit cleaner, and can be
>>> explicitly searched/found.
>>
>> It indeed makes it easier to parse.
>>
>> I'll wait and see if there are some other use cases, but for now I'm
>> inclined to agree with you. (At least, my gut feeling tells me that I
>> dislike associating a version number to a Relation, though I have less
>> reservations to associate it with other non-root Network Objects).
>>
>> Thanks,
>> Freek
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg