Hi Guys, I hope you like XML. I've just filled the nml-example repository with a whole bunch of examples and proposals that I like to go through next week at the OGF. If you haven't checked it out, do so now: svn checkout --username YourGridForgeName \ https://forge.ogf.org/svn/repos/nml-examples If you get a permission error, let me know off-list. The examples are also attached to this mail, but be aware that I may improve some typos and add clarifications in the coming days. The examples and proposals are: subtopology - hasNode four alternative proposals how to relate a topology and a node subtopology - hasTopology one example and three questions how to relate a topology to a subtopology (hopefully trivial after we decided on hasNode) subtopology - inbound-outbound-ports four proposals to decide on the term for ingress and egress ports subtopology - alias three proposal to relate a external port of a topology with its internal structure versioning - lifetime a (surely flawed) example how I interpreted Aaron's description of the current use of lifetime in IDC. versioning - aliases-lifetime versioning - aliases-version six proposals to describe the changes in a network over time using either a lifetime object or a version attribute vlans - compoundlink two questions on the exact name of the source/sink relation and the serial compound link relation vlans - vlan a proposal to describe vlans (Ethernet subnets) between hosts vlan - shared-switchingservice vlan - multiple-switchingservice <not yet written -- will follow sunday or monday> two proposals to describe multiple VLANs as one or more switching services inside a single node In case you wonder "haven't we decided on that already" -- in most cases, "yes" -- while going through previous examples, I've noted some small discrepancies. For examples some examples used "source" relation, while others used "hasSource". I don't care, so we should decide, and that's what this is about: make sure that we make a decision. Note the consensus and make the decision authoritative, so we can refer back to it, and update the previous examples to comply with the decision. I did my best to make all proposals stand on it's own, and VERY much hope that the decision for most proposals is a formality without discussion. Regards, Freek
Freek Dijkstra wrote:
Note the consensus and make the decision authoritative, so we can refer back to it, and update the previous examples to comply with the decision.
It's late. This sentence came out wrong. I meant to say: Let's see if we can reach a consensus on the majority of these alternatives. Write down what that consensus is for all non-controversial proposals, so we can refer back to it and start writing authoritative examples with these decisions in mind. Formally, I like to use the OGF to discuss the examples, make sure they are clear, and understand where there are still improvements to make (either in current or new alternative proposals), than go through the controversial examples on the mailing list and phone calls in the next weeks and see if we can reach formal "WG consensus" on the mailing list by April. I like to make sure that the folks who can't make it to Oxford still have their say in it. That at least is the plan. I'm sure the interaction with the NSI folks will spur some new ideas and proposals. :) See you in a few days, Freek
Hi Freek/All; 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 ... 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. - 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 - 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. - 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. - 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. Thanks; -jason On 3/9/12 3:49 PM, thus spake Freek Dijkstra:
Hi Guys,
I hope you like XML.
I've just filled the nml-example repository with a whole bunch of examples and proposals that I like to go through next week at the OGF.
If you haven't checked it out, do so now: svn checkout --username YourGridForgeName \ https://forge.ogf.org/svn/repos/nml-examples
If you get a permission error, let me know off-list. The examples are also attached to this mail, but be aware that I may improve some typos and add clarifications in the coming days.
The examples and proposals are:
subtopology - hasNode four alternative proposals how to relate a topology and a node
subtopology - hasTopology one example and three questions how to relate a topology to a subtopology (hopefully trivial after we decided on hasNode)
subtopology - inbound-outbound-ports four proposals to decide on the term for ingress and egress ports
subtopology - alias three proposal to relate a external port of a topology with its internal structure
versioning - lifetime a (surely flawed) example how I interpreted Aaron's description of the current use of lifetime in IDC.
versioning - aliases-lifetime versioning - aliases-version six proposals to describe the changes in a network over time using either a lifetime object or a version attribute
vlans - compoundlink two questions on the exact name of the source/sink relation and the serial compound link relation
vlans - vlan a proposal to describe vlans (Ethernet subnets) between hosts
vlan - shared-switchingservice vlan - multiple-switchingservice <not yet written -- will follow sunday or monday> two proposals to describe multiple VLANs as one or more switching services inside a single node
In case you wonder "haven't we decided on that already" -- in most cases, "yes" -- while going through previous examples, I've noted some small discrepancies. For examples some examples used "source" relation, while others used "hasSource". I don't care, so we should decide, and that's what this is about: make sure that we make a decision. Note the consensus and make the decision authoritative, so we can refer back to it, and update the previous examples to comply with the decision.
I did my best to make all proposals stand on it's own, and VERY much hope that the decision for most proposals is a formality without discussion.
Regards, Freek
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
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>
- 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).
- 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.)
- 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). 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
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@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Jason Zurawski wrote:
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 />
I did not mean versioning of the schema, but versioning of the (topology) instance. E.g. F: "Hey guy's, this is my latest network!" <nml:topo id="freekishnet" version="2012-03-12"> <!-- awesome stuff --> </nml:topo> (... After a well deserved night's sleep ...) F: "Hey guys, I added a unloaded swallow to my network today, totally putting yesterday's network in shame!" <nml:topo id="freekishnet" version="2012-03-13"> <!-- even more awesome stuff --> </nml:topo> It has the same identifier, but because it has a different version, you know which one is the latest-and-greatest. Freek
Hi Freek/All; On 3/12/12 2:16 PM, thus spake Freek Dijkstra:
Jason Zurawski wrote:
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 />
I did not mean versioning of the schema, but versioning of the (topology) instance.
E.g.
F: "Hey guy's, this is my latest network!"
<nml:topo id="freekishnet" version="2012-03-12"> <!-- awesome stuff --> </nml:topo>
(... After a well deserved night's sleep ...)
F: "Hey guys, I added a unloaded swallow to my network today, totally putting yesterday's network in shame!"
<nml:topo id="freekishnet" version="2012-03-13"> <!-- even more awesome stuff --> </nml:topo>
It has the same identifier, but because it has a different version, you know which one is the latest-and-greatest.
This still seems like a lifetime to me:
<nml:topo id="freekishnet"> <lifetime> <start>Sun Mar 11 13:25:33 EDT 2012</start> <end>Mon Mar 12 17:20:00 EDT 2012</end> </lifetime> <!-- awesome stuff --> </nml:topo>
<nml:topo id="freekishnet"> <lifetime> <start>Mon Mar 12 17:20:00 EDT 2012</start> <!-- lack of end or duration means current? --> </lifetime> <!-- more awesome stuff --> </nml:topo>
It becomes explicit that one has a shelf life, and the other is ongoing. With 'version' you are left with an arbitrary mark that something is different (and it may be the case that its a date, but it could be just '1' or '2a'). If we see the later being more common, I suppose the use case is different and in this case we may want both to be allowed. -jason
W dniu 2012-03-12 21:23, Jason Zurawski pisze:
Hi Freek/All;
On 3/12/12 2:16 PM, thus spake Freek Dijkstra:
Jason Zurawski wrote:
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 />
I did not mean versioning of the schema, but versioning of the (topology) instance.
E.g.
F: "Hey guy's, this is my latest network!"
<nml:topo id="freekishnet" version="2012-03-12"> <!-- awesome stuff --> </nml:topo>
(... After a well deserved night's sleep ...)
F: "Hey guys, I added a unloaded swallow to my network today, totally putting yesterday's network in shame!"
<nml:topo id="freekishnet" version="2012-03-13"> <!-- even more awesome stuff --> </nml:topo>
It has the same identifier, but because it has a different version, you know which one is the latest-and-greatest.
This still seems like a lifetime to me:
<nml:topo id="freekishnet"> <lifetime> <start>Sun Mar 11 13:25:33 EDT 2012</start> <end>Mon Mar 12 17:20:00 EDT 2012</end> </lifetime> <!-- awesome stuff --> </nml:topo>
<nml:topo id="freekishnet"> <lifetime> <start>Mon Mar 12 17:20:00 EDT 2012</start> <!-- lack of end or duration means current? --> </lifetime> <!-- more awesome stuff --> </nml:topo>
It becomes explicit that one has a shelf life, and the other is ongoing. With 'version' you are left with an arbitrary mark that something is different (and it may be the case that its a date, but it could be just '1' or '2a'). If we see the later being more common, I suppose the use case is different and in this case we may want both to be allowed.
I'm also thinking that the lifetime element can be used for versioning. <start> may be misleading but I would accept having the optional timestamp element inside the lifetime <lifetime> <timestamp>Mon Mar 12 17:20:00 EDT 2012</timestamp> </lifetime> Roman
-jason _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Hi, On 12 Mar 2012, at 21:23, Jason Zurawski wrote:
This still seems like a lifetime to me:
<nml:topo id="freekishnet"> <lifetime> <start>Sun Mar 11 13:25:33 EDT 2012</start> <end>Mon Mar 12 17:20:00 EDT 2012</end> </lifetime> <!-- awesome stuff --> </nml:topo>
<nml:topo id="freekishnet"> <lifetime> <start>Mon Mar 12 17:20:00 EDT 2012</start> <!-- lack of end or duration means current? --> </lifetime> <!-- more awesome stuff --> </nml:topo>
It becomes explicit that one has a shelf life, and the other is ongoing. With 'version' you are left with an arbitrary mark that something is different (and it may be the case that its a date, but it could be just '1' or '2a'). If we see the later being more common, I suppose the use case is different and in this case we may want both to be allowed.
While we so far have not shied away from verbose solutions, the above is way too verbose for my liking. In your proposal, when I announce a new topology, I have to send the old one with an ended lifetime, and also the new one with a lifetime element, with just a start. Version numbers have worked for DNS, I see no reason why this would be any different. At the same time, Lifetime does have a valid use for describing reservations, virtual machines, or crossconnects. This use of Lifetime to me is a completely different meaning than versioning topologies. A reservation ceases to exist after its end-time. A topology is not something that usually has an intended lifetime, it is, and may be updated in the future. Jeroen.
Hi Jeroen/All; On 3/13/12 1:45 AM, thus spake Jeroen van der Ham:
Hi,
On 12 Mar 2012, at 21:23, Jason Zurawski wrote:
This still seems like a lifetime to me:
<nml:topo id="freekishnet"> <lifetime> <start>Sun Mar 11 13:25:33 EDT 2012</start> <end>Mon Mar 12 17:20:00 EDT 2012</end> </lifetime> <!-- awesome stuff --> </nml:topo>
<nml:topo id="freekishnet"> <lifetime> <start>Mon Mar 12 17:20:00 EDT 2012</start> <!-- lack of end or duration means current? --> </lifetime> <!-- more awesome stuff --> </nml:topo>
It becomes explicit that one has a shelf life, and the other is ongoing. With 'version' you are left with an arbitrary mark that something is different (and it may be the case that its a date, but it could be just '1' or '2a'). If we see the later being more common, I suppose the use case is different and in this case we may want both to be allowed.
While we so far have not shied away from verbose solutions, the above is way too verbose for my liking. In your proposal, when I announce a new topology, I have to send the old one with an ended lifetime, and also the new one with a lifetime element, with just a start.
I don't see this as 'sending' anything, its a bookeeping step the same as creating a new topology. The amount of work (and verbosity) is similar to any other operation.
Version numbers have worked for DNS, I see no reason why this would be any different.
Clarify this - is 'version' just something that lives on the 'topology' element, or is version something that all elements now contain? Can we version nodes (e.g. a switch got a firmware update, or new ports added), or links, or ports, or anything else in our universe?
At the same time, Lifetime does have a valid use for describing reservations, virtual machines, or crossconnects. This use of Lifetime to me is a completely different meaning than versioning topologies. A reservation ceases to exist after its end-time. A topology is not something that usually has an intended lifetime, it is, and may be updated in the future.
I have always rejected ideas that don't add 'new' information. I don't see version as adding anything new that lifetime doesn't already feature. Unless there is a compelling new use case that has not been described yet, I remain unconvinced that its vastly different. Thanks; -jason
All, Can we agree that we have two use cases: * A link with a certain reservation (with start and endtime) * Update of the internal of a topology And two techniques to represent either: * Lifetime object with start time and optional end time * version (sequence number) which can be interpreted as a start time Looking at the use cases individually, I would say that the most elegant solution for use case 1 (reservation time) is a lifetime object. The most elegant solution for use case 2 (updates) is a version sequence number. Looking at both use cases, I have a preference to pick one solution, rather than two solutions. My initial idea was to pick version sequence number, and get rid of lifetime. Jason proposes to keep lifetime, and use it for use cases. Jeroen proposes to keep both concepts. Despite my initial preference, I know am inclined to keep both concepts. The reason is that I can very well envision the following scenario: telco: "Here is your link reservation, it's from 2 to 4 tomorrow" user: "thanks, I found out I need it a bit longer, can you extend my reservation?" telco: "Sure, here is an update of your reservation. it's now from 2 to 5 tomorrow" user: "great" In this scenario, one can attach a version sequence number to a lifetime object. (let me know if you want the XML version of the above exchange.) The mere fact that it is possible to logically combine the concepts in a single message with a perfectly valid meaning got me convinced that we're dealing with two distinct attributes. Hence, I changed my opinion, and have a slight preference to keep both concepts: both lifetime object and version attribute.
Clarify this - is 'version' just something that lives on the 'topology' element, or is version something that all elements now contain? Can we version nodes (e.g. a switch got a firmware update, or new ports added), or links, or ports, or anything else in our universe?
I'm currently only interested in attaching version to a topology, but wouldn't object to attaching it to other Network Object. What is your preference? Only attach it to a Topology, or also to Nodes and other Network Objects? Regards, Freek
On Mar 13, 2012, at 10:15 AM, Freek Dijkstra wrote:
All,
Can we agree that we have two use cases: * A link with a certain reservation (with start and endtime) * Update of the internal of a topology
Given hierarchical and abstracted topologies, I don't see these as different cases. We have groups building networks on-top of "reserved" links. Jeff
And two techniques to represent either: * Lifetime object with start time and optional end time * version (sequence number) which can be interpreted as a start time
Looking at the use cases individually, I would say that the most elegant solution for use case 1 (reservation time) is a lifetime object. The most elegant solution for use case 2 (updates) is a version sequence number.
Looking at both use cases, I have a preference to pick one solution, rather than two solutions.
My initial idea was to pick version sequence number, and get rid of lifetime. Jason proposes to keep lifetime, and use it for use cases. Jeroen proposes to keep both concepts.
Despite my initial preference, I know am inclined to keep both concepts. The reason is that I can very well envision the following scenario:
telco: "Here is your link reservation, it's from 2 to 4 tomorrow" user: "thanks, I found out I need it a bit longer, can you extend my reservation?" telco: "Sure, here is an update of your reservation. it's now from 2 to 5 tomorrow" user: "great"
In this scenario, one can attach a version sequence number to a lifetime object. (let me know if you want the XML version of the above exchange.)
The mere fact that it is possible to logically combine the concepts in a single message with a perfectly valid meaning got me convinced that we're dealing with two distinct attributes.
Hence, I changed my opinion, and have a slight preference to keep both concepts: both lifetime object and version attribute.
Clarify this - is 'version' just something that lives on the 'topology' element, or is version something that all elements now contain? Can we version nodes (e.g. a switch got a firmware update, or new ports added), or links, or ports, or anything else in our universe?
I'm currently only interested in attaching version to a topology, but wouldn't object to attaching it to other Network Object. What is your preference? Only attach it to a Topology, or also to Nodes and other Network Objects?
Regards, Freek
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Hi, On 13 Mar 2012, at 17:05, Jeff W. Boote wrote:
Can we agree that we have two use cases: * A link with a certain reservation (with start and endtime) * Update of the internal of a topology
Given hierarchical and abstracted topologies, I don't see these as different cases. We have groups building networks on-top of "reserved" links.
Again, a request is different from a topology that is providing the resources for such a request. Following the use-case that Freek mentioned above: you could send a request for a reservation, ask for an extension and get a new version of your reservation. Jeroen.
W dniu 2012-03-13 17:11, Jeroen van der Ham pisze:
Hi,
On 13 Mar 2012, at 17:05, Jeff W. Boote wrote:
Can we agree that we have two use cases: * A link with a certain reservation (with start and endtime) * Update of the internal of a topology Given hierarchical and abstracted topologies, I don't see these as different cases. We have groups building networks on-top of "reserved" links. Again, a request is different from a topology that is providing the resources for such a request. Following the use-case that Freek mentioned above: you could send a request for a reservation, ask for an extension and get a new version of your reservation.
Now I'm a bit lost :) I thought that version was assigned to the topology or its elements, not a reservation. Correct me if I'm wrong. Roman
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
On Mar 13, 2012, at 11:11 AM, Jeroen van der Ham wrote:
Hi,
On 13 Mar 2012, at 17:05, Jeff W. Boote wrote:
Can we agree that we have two use cases: * A link with a certain reservation (with start and endtime) * Update of the internal of a topology
Given hierarchical and abstracted topologies, I don't see these as different cases. We have groups building networks on-top of "reserved" links.
Again, a request is different from a topology that is providing the resources for such a request. Following the use-case that Freek mentioned above: you could send a request for a reservation, ask for an extension and get a new version of your reservation.
The results of the first request can become the topology for a new network, and that can be used as the basis to provide another provisioning entity. There is no difference. Jeff
This all seems to boils down to a few things: 1) do we have an element with both a start time and an end time, or do we have an element with just a start time (where the start time could simply be relative to the previous start time, and have no meaning outside of the version numbers) 2) do the values in that element apply to just the network element it is contained in, or to all the network elements that are contained in that network element The lifetime object as currently proposed implies that the answer to 1) is start/end time, and 2) that it only applies to the current network element The version object that freek is proposing implies that the answer to 1) is just start time, and 2) that it applies to all elements contained in that network element The problem I see with the 'version' proposal is that contained-in is just one type of relationship between elements. In the 'a new reservation has a new version' example that Jeroen sent to Jeff, if reservation contains a pointer to topology that make it up, and those elements are contained in a given topology, which elements in which topology are being referenced? An example of the above (simplified for the example): Topology vT1 - Node A - Node B Reservation vV1 - (Giving it a version number disassociated with the topology. If you say "but they're associated with a topology", then i'll just use an example where one topology contains an element with a pointer to an element in another topology) - p(Node A) - p(Node B) Topology vT2 - Node A - Node B (changed) In this example, a Reservation was made using Topology version T1. After the reservation was made, and saved elsewhere, the Topology is changed properties of Node B. If someone is doing a post-mortem of Reservation vV1, which Topology should they be looking at to resolve the pointer for Node B? If every network element has a 'lifetime' element, then it's easy to resolve it, you just find the elements whose lifetimes overlap the one you're interested in. Relatedly, what happens if an element is contained-in multiple other elements (e.g. a Topology and an Administrative Domain, or are we making Topology a special group that is more equal than the other groups)? There are other lifetime benefits (e.g. multiple versions of an element can be in the same topology so you can pass around a single topology that gives you past and present state, or you can pull elements outside of their enclosing 'topology' and still make sense of them). Cheers, Aaron On Mar 13, 2012, at 12:15 PM, Freek Dijkstra wrote:
All,
Can we agree that we have two use cases: * A link with a certain reservation (with start and endtime) * Update of the internal of a topology
And two techniques to represent either: * Lifetime object with start time and optional end time * version (sequence number) which can be interpreted as a start time
Looking at the use cases individually, I would say that the most elegant solution for use case 1 (reservation time) is a lifetime object. The most elegant solution for use case 2 (updates) is a version sequence number.
Looking at both use cases, I have a preference to pick one solution, rather than two solutions.
My initial idea was to pick version sequence number, and get rid of lifetime. Jason proposes to keep lifetime, and use it for use cases. Jeroen proposes to keep both concepts.
Despite my initial preference, I know am inclined to keep both concepts. The reason is that I can very well envision the following scenario:
telco: "Here is your link reservation, it's from 2 to 4 tomorrow" user: "thanks, I found out I need it a bit longer, can you extend my reservation?" telco: "Sure, here is an update of your reservation. it's now from 2 to 5 tomorrow" user: "great"
In this scenario, one can attach a version sequence number to a lifetime object. (let me know if you want the XML version of the above exchange.)
The mere fact that it is possible to logically combine the concepts in a single message with a perfectly valid meaning got me convinced that we're dealing with two distinct attributes.
Hence, I changed my opinion, and have a slight preference to keep both concepts: both lifetime object and version attribute.
Clarify this - is 'version' just something that lives on the 'topology' element, or is version something that all elements now contain? Can we version nodes (e.g. a switch got a firmware update, or new ports added), or links, or ports, or anything else in our universe?
I'm currently only interested in attaching version to a topology, but wouldn't object to attaching it to other Network Object. What is your preference? Only attach it to a Topology, or also to Nodes and other Network Objects?
Regards, Freek
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Internet2 Spring Member Meeting April 22-25, 2012 - Arlington, Virginia http://events.internet2.edu/2012/spring-mm/
Hi all- I think there is a definite difference between a lifetime element and a version number/time stamp. The former bounds the existance of an element, and generally a priori. The latter simply indicates that an element has changed. An element could conceivably change many times during its lifetime...right? And when its' lifetime expires and the element is destroyed, the containing element and possibly any referencing elements must reflect that change...Without versioning, you have no choice but to analyze the entire topoDB to identify those components that have changed. Even though an active reservation instance may indeed be "inserted" into the topology and becomes a resource for other allocation, the fact that it is now a resource in the topodb changes its role - the reservation still exists with its lifetime, but those allocated resources are now part of the resource database too. IMO the topological element and the reservation element should be two different objects - even though they are based upon the same data plane manifestation. They should [IMO] be related somehow, but they should be different topological element instances. If a resource in the topoDB is deactivated and no longer in the topoDB, then the element that contained that element has changed. I.e. an update has occurred and the version number/time stamp of that containing element should reflect that...the /lifetime/ of the containing element has not changed - but its state has...and the version simply indicates that it has been modified. So I concur with Jeff that connections can form the basis for new topology elements in the topoDB. But even though the two constructs may look similar, there should be two separate elements: one for the reservation, and one for the topology element. So in this respect I would back Jeroen in that I think both the lifetime and the version elements have different purposes and are both necessary. Thoughts? Jerry On 3/13/12 1:47 PM, Aaron Brown wrote:
This all seems to boils down to a few things:
1) do we have an element with both a start time and an end time, or do we have an element with just a start time (where the start time could simply be relative to the previous start time, and have no meaning outside of the version numbers) 2) do the values in that element apply to just the network element it is contained in, or to all the network elements that are contained in that network element
The lifetime object as currently proposed implies that the answer to 1) is start/end time, and 2) that it only applies to the current network element The version object that freek is proposing implies that the answer to 1) is just start time, and 2) that it applies to all elements contained in that network element
The problem I see with the 'version' proposal is that contained-in is just one type of relationship between elements. In the 'a new reservation has a new version' example that Jeroen sent to Jeff, if reservation contains a pointer to topology that make it up, and those elements are contained in a given topology, which elements in which topology are being referenced? An example of the above (simplified for the example):
Topology vT1 - Node A - Node B
Reservation vV1 - (Giving it a version number disassociated with the topology. If you say "but they're associated with a topology", then i'll just use an example where one topology contains an element with a pointer to an element in another topology) - p(Node A) - p(Node B)
Topology vT2 - Node A - Node B (changed)
In this example, a Reservation was made using Topology version T1. After the reservation was made, and saved elsewhere, the Topology is changed properties of Node B. If someone is doing a post-mortem of Reservation vV1, which Topology should they be looking at to resolve the pointer for Node B?
If every network element has a 'lifetime' element, then it's easy to resolve it, you just find the elements whose lifetimes overlap the one you're interested in.
Relatedly, what happens if an element is contained-in multiple other elements (e.g. a Topology and an Administrative Domain, or are we making Topology a special group that is more equal than the other groups)?
There are other lifetime benefits (e.g. multiple versions of an element can be in the same topology so you can pass around a single topology that gives you past and present state, or you can pull elements outside of their enclosing 'topology' and still make sense of them).
Cheers, Aaron
On Mar 13, 2012, at 12:15 PM, Freek Dijkstra wrote:
All,
Can we agree that we have two use cases: * A link with a certain reservation (with start and endtime) * Update of the internal of a topology
And two techniques to represent either: * Lifetime object with start time and optional end time * version (sequence number) which can be interpreted as a start time
Looking at the use cases individually, I would say that the most elegant solution for use case 1 (reservation time) is a lifetime object. The most elegant solution for use case 2 (updates) is a version sequence number.
Looking at both use cases, I have a preference to pick one solution, rather than two solutions.
My initial idea was to pick version sequence number, and get rid of lifetime. Jason proposes to keep lifetime, and use it for use cases. Jeroen proposes to keep both concepts.
Despite my initial preference, I know am inclined to keep both concepts. The reason is that I can very well envision the following scenario:
telco: "Here is your link reservation, it's from 2 to 4 tomorrow" user: "thanks, I found out I need it a bit longer, can you extend my reservation?" telco: "Sure, here is an update of your reservation. it's now from 2 to 5 tomorrow" user: "great"
In this scenario, one can attach a version sequence number to a lifetime object. (let me know if you want the XML version of the above exchange.)
The mere fact that it is possible to logically combine the concepts in a single message with a perfectly valid meaning got me convinced that we're dealing with two distinct attributes.
Hence, I changed my opinion, and have a slight preference to keep both concepts: both lifetime object and version attribute.
Clarify this - is 'version' just something that lives on the 'topology' element, or is version something that all elements now contain? Can we version nodes (e.g. a switch got a firmware update, or new ports added), or links, or ports, or anything else in our universe?
I'm currently only interested in attaching version to a topology, but wouldn't object to attaching it to other Network Object. What is your preference? Only attach it to a Topology, or also to Nodes and other Network Objects?
Regards, Freek
_______________________________________________ nml-wg mailing list nml-wg@ogf.org <mailto:nml-wg@ogf.org> https://www.ogf.org/mailman/listinfo/nml-wg
Internet2 Spring Member Meeting April 22-25, 2012 - Arlington, Virginia http://events.internet2.edu/2012/spring-mm/
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Hi Aaron, Thanks for your constructive mail.
1) do we have an element with both a start time and an end time, or do we have an element with just a start time (where the start time could simply be relative to the previous start time, and have no meaning outside of the version numbers) 2) do the values in that element apply to just the network element it is contained in, or to all the network elements that are contained in that network element
The lifetime object as currently proposed implies that the answer to 1) is start/end time, and 2) that it only applies to the current network element The version object that freek is proposing implies that the answer to 1) is just start time, and 2) that it applies to all elements contained in that network element
Good analysis, we agree on this.
The problem I see with the 'version' proposal is that contained-in is just one type of relationship between elements.
While formulating an answer, I found it problematic to come to a simple answer where the version or lifetime would not apply to the top level element, but also to the childs elements. Perhaps it is easier to simply say that a version or lifetime only applies to the object and it's attributes, but not to it's child elements. There are two arguments for this. You already mentioned the argument that it is unclear if a refId is a child or not; another argument is that it is unclear if a parent element no longer included a child: does that mean that the child's lifetime is ended, or that there simply is no update. Example: Topo v=1 Node A Node B Node C Topo v=2 Node A Node B Node D Does this mean that Node C is gone, or that this is some abstracted topology, and that Node C is simply not mentioned here (perhaps this topology has >1000 Nodes, and this is just some abstracted view). In this case a Lifetime object for Node C would make things explicit, (I can also see some clever hack where version is used to denote this information, but Lifetime is the better choice here). So far you've convinced me that the Lifetime object has its merits. Good. You still have not convinced that we can get rid of the version attribute. Let me first answer your question though:
Topology vT1 - Node A - Node B
Reservation vV1 - [...] - p(Node A) - p(Node B)
Topology vT2 - Node A - Node B (changed)
In this example, a Reservation was made using Topology version T1. After the reservation was made, and saved elsewhere, the Topology is changed properties of Node B. If someone is doing a post-mortem of Reservation vV1, which Topology should they be looking at to resolve the pointer for Node B?
They should look at Topology vT2 for the attributes of Node B after t > T2. This is exactly the same as with a lifetime object, only (slightly) more verbose: Topology X lifetime start=T1, end=T2 - Node A - Node B Reservation vV1 - [...] - p(Node A) - p(Node B) Topology X lifetime start=T2, end=<undefined> - Node A - Node B (changed) In the above, we applied the exact same semantics to `version=T` as to `lifetime(start=T, end=<undefined>)`. So this is interchangable, and poses not pro or con against one or the other proposal (well, lifetime is more flexible because it has an end-time, version is shorter and the terminology seem to match closer tot the usage here. That has been argued before) I can conclude that the lifetime object and version object can be used interchangeably in the above example. Nice, but let's now turn to the example Jeroen and I gave. The above is _not_ Jeroen's example. The example above changed Node B, Jeroen's changed the reservation time of the Reservation:
telco: "Here is your link reservation, it's from 2 to 4 tomorrow" user: "thanks, I found out I need it a bit longer, can you extend my reservation?" telco: "Sure, here is an update of your reservation. it's now from 2 to 5 tomorrow" user: "great"
As a schema: Reservation id=R version=1 lifetime(start=2:00 end=4:00) p(Node A) p(Node B) Reservation id=R version=2 lifetime(start=2:00 end=5:00) p(Node A) p(Node B) As you see I need both the version AND lifetime object to convey this message. Now you seem to argue that it is possible to represent this using only the lifetime object. Unfortunately, I seem to fail to see how. Could you write down how you anticipate these message looks like using only the lifetime object? Lacking that example, I still think we need both a Lifetime object and a version attribute. Thanks, Freek
Hey Freek, You've convinced me :) I'm happy with a version and a lifetime element, as long as they only apply to the current element, and not to other somehow-related elements. It'd probably be good if the version element functioned as a "created" timestamp so you can figure out when the new version of an element came into existence. This would allow easier post-mortems of network state. Cheers, Aaron On Mar 13, 2012, at 6:42 PM, Freek Dijkstra wrote:
Hi Aaron,
Thanks for your constructive mail.
1) do we have an element with both a start time and an end time, or do we have an element with just a start time (where the start time could simply be relative to the previous start time, and have no meaning outside of the version numbers) 2) do the values in that element apply to just the network element it is contained in, or to all the network elements that are contained in that network element
The lifetime object as currently proposed implies that the answer to 1) is start/end time, and 2) that it only applies to the current network element The version object that freek is proposing implies that the answer to 1) is just start time, and 2) that it applies to all elements contained in that network element
Good analysis, we agree on this.
The problem I see with the 'version' proposal is that contained-in is just one type of relationship between elements.
While formulating an answer, I found it problematic to come to a simple answer where the version or lifetime would not apply to the top level element, but also to the childs elements. Perhaps it is easier to simply say that a version or lifetime only applies to the object and it's attributes, but not to it's child elements.
There are two arguments for this. You already mentioned the argument that it is unclear if a refId is a child or not; another argument is that it is unclear if a parent element no longer included a child: does that mean that the child's lifetime is ended, or that there simply is no update.
Example: Topo v=1 Node A Node B Node C
Topo v=2 Node A Node B Node D
Does this mean that Node C is gone, or that this is some abstracted topology, and that Node C is simply not mentioned here (perhaps this topology has >1000 Nodes, and this is just some abstracted view). In this case a Lifetime object for Node C would make things explicit, (I can also see some clever hack where version is used to denote this information, but Lifetime is the better choice here).
So far you've convinced me that the Lifetime object has its merits. Good. You still have not convinced that we can get rid of the version attribute.
Let me first answer your question though:
Topology vT1 - Node A - Node B
Reservation vV1 - [...] - p(Node A) - p(Node B)
Topology vT2 - Node A - Node B (changed)
In this example, a Reservation was made using Topology version T1. After the reservation was made, and saved elsewhere, the Topology is changed properties of Node B. If someone is doing a post-mortem of Reservation vV1, which Topology should they be looking at to resolve the pointer for Node B?
They should look at Topology vT2 for the attributes of Node B after t > T2.
This is exactly the same as with a lifetime object, only (slightly) more verbose:
Topology X lifetime start=T1, end=T2 - Node A - Node B
Reservation vV1 - [...] - p(Node A) - p(Node B)
Topology X lifetime start=T2, end=<undefined> - Node A - Node B (changed)
In the above, we applied the exact same semantics to `version=T` as to `lifetime(start=T, end=<undefined>)`. So this is interchangable, and poses not pro or con against one or the other proposal (well, lifetime is more flexible because it has an end-time, version is shorter and the terminology seem to match closer tot the usage here. That has been argued before)
I can conclude that the lifetime object and version object can be used interchangeably in the above example.
Nice, but let's now turn to the example Jeroen and I gave.
The above is _not_ Jeroen's example. The example above changed Node B, Jeroen's changed the reservation time of the Reservation:
telco: "Here is your link reservation, it's from 2 to 4 tomorrow" user: "thanks, I found out I need it a bit longer, can you extend my reservation?" telco: "Sure, here is an update of your reservation. it's now from 2 to 5 tomorrow" user: "great"
As a schema:
Reservation id=R version=1 lifetime(start=2:00 end=4:00) p(Node A) p(Node B)
Reservation id=R version=2 lifetime(start=2:00 end=5:00) p(Node A) p(Node B)
As you see I need both the version AND lifetime object to convey this message.
Now you seem to argue that it is possible to represent this using only the lifetime object. Unfortunately, I seem to fail to see how. Could you write down how you anticipate these message looks like using only the lifetime object?
Lacking that example, I still think we need both a Lifetime object and a version attribute.
Thanks, Freek
Internet2 Spring Member Meeting April 22-25, 2012 - Arlington, Virginia http://events.internet2.edu/2012/spring-mm/
I agree. Jeff On Mar 14, 2012, at 6:05 AM, Aaron Brown wrote:
Hey Freek,
You've convinced me :) I'm happy with a version and a lifetime element, as long as they only apply to the current element, and not to other somehow-related elements. It'd probably be good if the version element functioned as a "created" timestamp so you can figure out when the new version of an element came into existence. This would allow easier post-mortems of network state.
Cheers, Aaron
On Mar 13, 2012, at 6:42 PM, Freek Dijkstra wrote:
Hi Aaron,
Thanks for your constructive mail.
1) do we have an element with both a start time and an end time, or do we have an element with just a start time (where the start time could simply be relative to the previous start time, and have no meaning outside of the version numbers) 2) do the values in that element apply to just the network element it is contained in, or to all the network elements that are contained in that network element
The lifetime object as currently proposed implies that the answer to 1) is start/end time, and 2) that it only applies to the current network element The version object that freek is proposing implies that the answer to 1) is just start time, and 2) that it applies to all elements contained in that network element
Good analysis, we agree on this.
The problem I see with the 'version' proposal is that contained-in is just one type of relationship between elements.
While formulating an answer, I found it problematic to come to a simple answer where the version or lifetime would not apply to the top level element, but also to the childs elements. Perhaps it is easier to simply say that a version or lifetime only applies to the object and it's attributes, but not to it's child elements.
There are two arguments for this. You already mentioned the argument that it is unclear if a refId is a child or not; another argument is that it is unclear if a parent element no longer included a child: does that mean that the child's lifetime is ended, or that there simply is no update.
Example: Topo v=1 Node A Node B Node C
Topo v=2 Node A Node B Node D
Does this mean that Node C is gone, or that this is some abstracted topology, and that Node C is simply not mentioned here (perhaps this topology has >1000 Nodes, and this is just some abstracted view). In this case a Lifetime object for Node C would make things explicit, (I can also see some clever hack where version is used to denote this information, but Lifetime is the better choice here).
So far you've convinced me that the Lifetime object has its merits. Good. You still have not convinced that we can get rid of the version attribute.
Let me first answer your question though:
Topology vT1 - Node A - Node B
Reservation vV1 - [...] - p(Node A) - p(Node B)
Topology vT2 - Node A - Node B (changed)
In this example, a Reservation was made using Topology version T1. After the reservation was made, and saved elsewhere, the Topology is changed properties of Node B. If someone is doing a post-mortem of Reservation vV1, which Topology should they be looking at to resolve the pointer for Node B?
They should look at Topology vT2 for the attributes of Node B after t > T2.
This is exactly the same as with a lifetime object, only (slightly) more verbose:
Topology X lifetime start=T1, end=T2 - Node A - Node B
Reservation vV1 - [...] - p(Node A) - p(Node B)
Topology X lifetime start=T2, end=<undefined> - Node A - Node B (changed)
In the above, we applied the exact same semantics to `version=T` as to `lifetime(start=T, end=<undefined>)`. So this is interchangable, and poses not pro or con against one or the other proposal (well, lifetime is more flexible because it has an end-time, version is shorter and the terminology seem to match closer tot the usage here. That has been argued before)
I can conclude that the lifetime object and version object can be used interchangeably in the above example.
Nice, but let's now turn to the example Jeroen and I gave.
The above is _not_ Jeroen's example. The example above changed Node B, Jeroen's changed the reservation time of the Reservation:
telco: "Here is your link reservation, it's from 2 to 4 tomorrow" user: "thanks, I found out I need it a bit longer, can you extend my reservation?" telco: "Sure, here is an update of your reservation. it's now from 2 to 5 tomorrow" user: "great"
As a schema:
Reservation id=R version=1 lifetime(start=2:00 end=4:00) p(Node A) p(Node B)
Reservation id=R version=2 lifetime(start=2:00 end=5:00) p(Node A) p(Node B)
As you see I need both the version AND lifetime object to convey this message.
Now you seem to argue that it is possible to represent this using only the lifetime object. Unfortunately, I seem to fail to see how. Could you write down how you anticipate these message looks like using only the lifetime object?
Lacking that example, I still think we need both a Lifetime object and a version attribute.
Thanks, Freek
Internet2 Spring Member Meeting April 22-25, 2012 - Arlington, Virginia http://events.internet2.edu/2012/spring-mm/
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
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@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Jerry Sobieski wrote:
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.
As always, if you have consideration or questions on a concept, do discuss it on the list. Some topics are new, we can postpose formal decisions while discussions last. That said, some things are non-controversial or have been discussed in the past and just need to be decided upon (e.g. write "nml:port" or "nml:Port", things like that), which I rather to soon. Also, I urge group members not to let a discussion get in the way of writing it down, providing examples, or even implementing a concept if it seems useful to you.
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'm meeting over lunch to explain and review the XML examples with Jeroen and Roman. That may not be a good time for lengthy discussions, so any other time, you're welcome to find me for a listening ear. Freek
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?
Hi Roman/All; I would rather let the namespace tell you information about 'layers' if possible, this is how we treat other elements (e.g. same namespace = same layer, different namesapces a merge in layers). If we do this, I believe the relationship doesnt need a specific 'name' or 'action', but I haven't thought about the implications fully. Thanks; -jason On 3/12/12 3:39 PM, thus spake Roman Łapacz:
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
W dniu 2012-03-12 22:43, Jason Zurawski pisze:
Hi Roman/All;
I would rather let the namespace tell you information about 'layers' if possible, this is how we treat other elements (e.g. same namespace = same layer, different namesapces a merge in layers). If we do this, I believe the relationship doesnt need a specific 'name' or 'action', but I haven't thought about the implications fully.
Right. I like namespaces for layers as well but what if we have to have layers (hierarchy) which in fact represent the same category. An example I'm thinking is an aggregation. Roman
Thanks;
-jason
On 3/12/12 3:39 PM, thus spake Roman Łapacz:
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
participants (7)
-
Aaron Brown -
Freek Dijkstra -
Jason Zurawski -
Jeff W. Boote -
Jeroen van der Ham -
Jerry Sobieski -
Roman Łapacz