The topology lookup service doesn't solve the problem of how does the lookup service learn topology?   While it simplifies a "user"s need to access topology, we still have to address how the lookup servers acquire their topology and assemble a global view.

So I think a Topology Server has a great deal of merit n that it offloads a lot of issues in topology merging and mangement, but it really doesn't answer the process of how we discover and keep topology state current.   Or how a network insures it is able to issue or acquire updates promptly.  

J

On 5/30/12 9:52 AM, Inder Monga wrote:
Why not use mechanisms that are used in perfSONAR - a topology lookup service?

What are the pros and cons of that approach?

Inder

Jeroen van der Ham wrote: 
Hi,

On 16 May 2012, at 19:46, Jerry Sobieski wrote:

The key is that we are exchanging world views - or updates to world views, not simply local topologies.

try this protocol sequence:
[...]



Instead of thinking up all kinds of scenarios, and exchange mechanisms, could we just please restrain this to referring to other implementations?

Most of what I've seen so far is all supported by OSPF. It has limited peering, abstraction, and simple update mechanisms. I propose we use that same mechanism, if there is anything that is wrong with that, please write what needs to be changed, and why.

The only thing we don't have at our disposal is multicast, but I think we can solve that by using a peer-to-peer overlay network. That requires some bootstrapping, but you need to coordinate with your neighbor(s) already, so that can become part of that exchange too.

Jeroen.

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

--
Inder Monga
510-486-6531
http://www.es.net
Follow us on Twitter: ESnetUpdates/Twitter
Visit our blog: ESnetUpdates Blog