I think there is a fairly simple way to distribute topo without melting down the network. Please look at the following: a) Walking the entire topology asking each NSA for local topology is slow and has major scaling issues. b) By creating an current world view by incrementally applying updates to an existing base worldview, and serving the entire worldview, or updates to it, we no longer need to touch every NSA to learn global topology...we can get it from a single topology server. c) We do not want a single centralized server, so we need a protocol that can merge partial views into a common view. i.e servers that can swap world views and converge. d) NSAs should be able to choose the NSAs they will exchange topology with, which means there will be NSAs that will not talk to us. Thus we cannot use the walking method to build a comprehensive world view. A topo agent should be able to pull topology down from another server, or request and accept a push from another server . The same agent should be able to serve a topology to another agent, or be able to accept a request to push a topology to that agent periodically. This is pretty simple really (IMO). The topology is a full world view as known by the agent, or updates to that worldview. The key is that we are exchanging world views - or updates to world views, not simply local topologies. try this protocol sequence: Server agent is initialized. Server has no topo - is empty. Client 1 is initialized with local topology, and a pointer to Server. Client 1 says hello to Server and and identifies itself. Server responds OK Client 1 pulls the full Server worldview...its empty so it is a very small transfer. Client 1 says "push updates to me <hourly>". Client 1 signs off. Server says hello to Client 1 and identifies itself. Client 1 responds OK. Server says "push updates to me <immediately>". Server signs off. Client 1 pushes updates to Server. Both Server and Client 1 have converged world views. Client 2 is initialized with local topology and pointer to Server. same exchange as above, but client 2 does not request push of updates (as it will contact the server and pull them periodically) At sign off server has topo for both client 1 and client 2, and client 2 has topo for both client 1 and 2. So an hour passes, and server now pushes client 2 updates to client 1. All NSAs are converged and have single world view. Server now is configured a pointer to topo server Peerserver1. Exchange as above with Server acting as client, and PeerServer1 acting as server. Full topos are exchanged first, and updates are arranged for later. Both sign off. Then Server pushes updates to its client 1. Some time later client 2 contacts Server and pulls updates. Now all NSA have converged world view. There are some obvious options to tweek this handshake.. maybe simplify it more... But this handshake allows NSAs to tune their own topology distribution processes to their own needs. The AAI of clients allows a NSA Topo Server to be selective about whom it will serve. But otherwise, an NSA can be either a server and/or client as configured by local domain administration. By transfering worldviews rather than local views only, we avoid the synaptic overload of NSAs all asking each other for topologies and updates- which is a scaling bomb. Interestingly, it does not prevent an NSA from walking the topology fishing for topology dumps. This server approach is not centralized per se as a client may query multiple servers for topology. And a client may act as server, serving other clients of its own...in which case we have realized a distributed peer network for topology distribution. This model allows us to start with a single NSA serving a single worldview, and all clients fetching that worldview. For practical reasons, the server can be initialized with the One True Worldview and clients offer no local topology. As clients begin managing their own topology, they can push their topology to the server which will override the server's older version. Seemlessly implementing a distributed process as domains are ready. Others may establish another server and arrange for the two servers to serve one another - now we have a redundant system... NSAs may be designed by default to contacting direct peers for topology services, or they may be manually configured to contact a remote NSA (not directly peered) for a topology feed. Either way as they feel proper... Thoughts? Jerry On 5/16/12 11:06 AM, John MacAuley wrote:
Okay, so besides the Propagate/DoNotPropagate policy I was thinking about, I definitely think we need a TimeToLive so we can expire learned topology data.
Is your lookup server looking up NSA or topology data?
John.
On 2012-05-16, at 10:55 AM, Radek Krzywania wrote:
Hi, Lookup service is not centralized topology. It just point to NSA where you can start topology discovery. Lookup services can be also distributed. I agree that not all NSAs will peer, so you need to discover starting from neighbors, that's obvious. What I am reluctant to, is to have different agents and different logic to serve them - one can see more details of some domains than others. I would risk that we will get the same functionality if all NSA has the same knowledge (same reachability graph, as topology is nothing more at this moment, no internals are provided). You will probably need to send a message or two more, instead of knowing something on your neighbour by default. "Privileged/Trusted domains" is something I could consider in v8, just after having NSI operationally deployed in few global telecommunication companies :)
Best regards Radek
________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
-----Original Message----- From: John MacAuley [mailto:john.macauley@surfnet.nl] Sent: Wednesday, May 16, 2012 4:16 PM To: radek.krzywania@man.poznan.pl Cc: 'Jeroen van der Ham'; 'NSI WG' Subject: Re: [Nsi-wg] Topology section
Here is the assumption:
a) All NSA will not have peering relationships, and therefore, not every NSA will be able to communicate with all other deployed NSA. b) A centralized topology solution is undesirable, and therefore, we need to distributed topology discovery. c) NSA agents will communicated with their provider NSA to discover network topology similar to the provider-to-provider discovery.
The problem is not a hard one as it has been solved in many distributed routing solutions. The key is controlled learning using directly connected peer NSA.
I thew the policy in there because we always throw the security issue into every message we define ;-)
John
On 2012-05-16, at 4:59 AM, Radek Krzywania wrote:
Hi, Re 1 an 2) - shouldn't we just define a kind of lookup service for all NSI agents in clound (it can be done in distributed manner, like DNS structure eg, or whatever), so the "yellow pages" are always known? Also I am not sure if I understand how "NSA 1 will compare the list of returned networks to the list it has already discovered, then make a decision on the individual network topology to retrieve from NSA 2." Shouldn't we have exactly the same topology in all NSI agents, for sake of clarity and simplicity? Re 3) - that's what I don't like. I understand you don’t trust PIONIER and don't want to share the topology with me (the detailed one), no offence :) However making agent different and distributing different topology data to those whom you trust or no makes whole system tough to design and horrible to implement. Also if there are some trusted sites which gets more details, someone may compromise one of such sites and get information now allowed to see (and use it for a network attack e.g.). The trusted domains will also have more information about neighbours, but what to do with such info since domain are independent? Even if you know something about a neighbour, you can't make decisions instead of him. Despite of that the agent will behave differently for domain it trust and knows more, and for the rest. That changes the logic of an agent, and thus make it more complex. My feeling is that the benefit of giving more info to trusted domains is less than implementation problems it generates. Best regards Radek
__________________________________________________________ ______________
Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl
__________________________________________________________ ______________
-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On
Of John MacAuley Sent: Wednesday, May 16, 2012 4:21 AM To: Jeroen van der Ham Cc: NSI WG Subject: Re: [Nsi-wg] Topology section
In addition to the topology data representation we will also need to define a topology discover mechanism that fits into the existing NSI framework. We will need to address the following discover requirements:
1. Support for controlled discovery. An NSA will attempt to build a view of network topology through communicating with peer NSA. Controlled discovery allows an NSA to make decisions on how it will discover the full network topology. For example, NSA 1 may ask NSA 2 for all the networks it has discovered, but not the detailed topology. NSA 1 will compare the list of returned networks to the list it has already discovered, then make a decision on the individual network topology to retrieve from NSA 2.
2. We will need a subscription mechanism for an NSA to register with a
Behalf peer
NSA for topology updates on networks of interest. If NSA 1 discovers NSA 3 through discovery with NSA 2, NSA 1 could register with NSA 2 for any topology updates on NSA 3.
3. Policy will need to be associated with communicated topology. We need additional investigation into this, but I would like to see the ability to associate a propagation policy with my topology. For example, I may allow UvA and NORDUnet to see my detailed topology, but they are not allowed to propagate, or advertise it to any other peer NSA. This will allow me to control distribution, and yes, I will need to trust the peer NSA not to propagate it.
John.
On 2012-05-11, at 3:19 AM, Jeroen van der Ham wrote:
Hi all,
I've made a start on the topology section for the NSI v2.0 document. It's not finished yet, but at least it contains some start. Unfortunately, I'll be on holiday next week, so I won't be able to further write on this. If others feel they can contribute, please do so. The document is available for reading at: https://docs.google.com/document/d/1HIo7uQl7DbTe_y- cnPOrqDkspoRBaTKVVrrldURurTk/edit Guy should be able to give out edit access rights too.
Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg