[Nml-wg] recursive topologies

[Jerry Sobieski]

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 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/20120305/839d4684/attachment.html>