[Nml-wg] XML Examples and Proposals

[Jerry Sobieski]

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 at ogf.org <mailto:nml-wg at 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 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/20120313/458105ab/attachment.html>