Hi guys-  Thanks for writing this up Freek.   Comments in line...

On 3/5/12 4:18 AM, Jeroen van der Ham wrote:
Hi,

On 4 Mar 2012, at 13:55, Freek Dijkstra wrote:

Hi all,

Last Friday Jerry and I had a short conversation. Jerry's idea is to
define recursive topologies, as he described in his slides to the list.

He convinced me that this is a great concept, as it allows for simple
topology abstraction.

While I wholeheartedly support the idea, I like to describe the concept
before giving a concrete proposal for changing the NML schema.
1. Connecting the (sub)topologies
2. Hierarchical identifiers
3. Updates and Versioning

Feedback is highly appreciated.

1. Connecting the (sub)topologies
I agree with this idea, and the option of defining aliases. This makes for a more stable inter-domain topology.
I would suggest that we allow abstracted topologies to contain some hints regarding internal availability.
I don't mind doing something like this as long as it is an optional announcement by the local network.  Thus a network can announce what they are comfortable announcing.  And an external path finder agent can gather as much topology as they can acquire.    I think some of the internal availability announcements become less important if we modified the Reservation Request to more acurately reflect the desired constraints - in particular to loosen the endpoint speciications to allow some selection criteria on a set of available endpoints.   But this latter approach is an issue for NSI, not really NML.

      
2. Hierarchical identifiers
No thanks.
Hmm...why that reaction?  :-)

I am on the fence on this.   I don't think we implemented URNs well in the current RDF/OWL topology.   The global nature seems awkward...  I just think we probably did not leverage the namespaces of the URNs effectively.

3. Updates and Versioning
In the Automated GOLE experiments I've found that being able to see a version of the topology used would be a nice feature. Currently the demo still uses a centralized topology, so knowing the used version is more important. Still, knowing when your neighbor last updated their topology can help debugging issues. So I think it would be a nice feature to have, although not necessarily something that we'd include in the schema itself though.
I concur that we need to transition the topology management to the networks/GOLEs themselves as soon as we can - this is the right thing to do.   But to do that, we should also have a well considered plan for how we expect NSAs to construct their world views - and have all NSA developers implement this as part of the transition.  There is no urgent rush - better to think it though first.    I would vote for the basic approach that each NSA builds a world view from direct neighbors and then they announce their world view,  rather than each domain simply announcing only their own local topology.   I think the world view approach will scale better.    Thoughts?

The version timestamp is useful I think when we move to the distributed mechanism.   If you want to suggest a RDF predicate, I can add it into the present topology.   I think the idea was that we could use timestamps to date each nested block of information...so that merging them could be done based on block timestamp rather than a more complex parser analysis.

J
  
Jeroen.





_______________________________________________
nml-wg mailing list
nml-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nml-wg