[Nml-wg] XML Examples and Proposals

[Aaron Brown]

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
> 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/

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