[Nml-wg] XML Examples and Proposals

[Freek Dijkstra]

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