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