[Nsi-wg] Topology section

[Aaron Brown]

Hey Jerry,

That description of how the perfSONAR topology service components work below differs some from how it ends up working in practice.

In practice, each domain registers their topology with the service. They have the option of updating the topology whenever they so desire, and can decide what of their topology they want to publish. Theoretically, this publishing model could support publishing multiple versions of the topology depending on who is asking. However, for now, we don't support that. Each topology service registers with the Lookup Service letting folks know what domains they have topology about. 

Clients (be they other OSCARS instances, or anyone else) can then lookup which topology service contains the topology for a given domain. They can then query the TS containing that topology. The clients are responsible for taking the per-domain pieces and assembling the global view.

When OSCARS does pathfinding, it does a search through its own topology. As it encounters pointers to new domains, it looks them and links them into its view.

There isn't a push mechanism for topology updates in this model, other than the OSCARS instance pushing its topology updates into the topology service. From that point on, it's all on the client side to ensure it is using an up to date view. We've talked about having a subscription service that would allow clients to subscribe to a specific TS, and receive updates. However, we've never gotten around to actually implementing it.

Personally, I like the idea of supporting both a subscription-based push model as well as a pull model for obtaining topology, and then building complex aggregation services (e.g. the OSPF-type system being discussed) on top of this. This allows for flexibility in building different kinds of aggregation services as well as allowing clients (be they NSI services, non-NSI services, or end users) build a model for topology discovery that suits them.

Cheers,
Aaron

On May 30, 2012, at 10:04 AM, Jerry Sobieski wrote:

> 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 at 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
>> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

ESCC/Internet2 Joint Techs
July 15-19, 2012 - Palo Alto, California
Hosted by Stanford University
http://events.internet2.edu/2012/jt-stanford/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120530/85f9670d/attachment-0001.html>