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
Hi guys- Thanks for writing this up Freek. Comments in line... On 3/5/12 4:18 AM, Jeroen van der Ham wrote: 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