[Nml-wg] XML Examples and Proposals

[Jeff W. Boote]

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 at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120314/d33c003c/attachment.html>