[Nml-wg] XML Examples and Proposals

[Aaron Brown]

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/

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