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-cnPOrqDkspoRBaTKVVrrldURu... Guy should be able to give out edit access rights too. Jeroen.
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 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-cnPOrqDkspoRBaTKVVrrldURu...
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
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 Behalf 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 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
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 Behalf 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 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
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
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
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
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.
Hi, People spend enough time on OSPF to make it reliable and good. I support the idea to get this concept into NSI and refactor it according to our needs. Unless some strong objections arise. Multicast is not an issue now. 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 Behalf Of Jeroen van der Ham Sent: Tuesday, May 29, 2012 1:15 PM To: Jerry Sobieski Cc: 'NSI WG' Subject: Re: [Nsi-wg] Topology section
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
This bootstrapping process is exactly what I described: How do you learn what the world looks like topologically when the NSA starts up? And how do you do this in a global distributed system of autonomous administrative domains and millions of untrusted [topology] consumers? the problem with OSPF is that it indeed floods link state announements. But this is a scaling problem in a large multidomain environments and can take a significant time for such protocols to converge..if ever they ever do. And even with OSPF not all toplogy is expressed...there are summarized LSA and areas...etc. all these hide topology in an attempt to make it scale better. and ospf is non trivial... It does not use IP. It has no authorization security either. And it is not exactly a web service:-). it has multiple timers just to tell when a neighbor is present and how/when to flood link state announcements. yet no way to determine if a LSA is to be trusted. And you still need to discover or configure the local topology...ospf can only do this in very limited cases...even in gmpls this was done by LMP...yet another protocol. further, the topology technologies/layering are defined in the protocol, rather than a separate topology standard...thus you need to change the protocol in order to enhance the topology descriptions. And the open source implementations (quaga, zebra, ...) are not small packages easily modified... These are some of the reasons why you never see OSPF in interdomain use. And rarely see it even in multilayer use. And why many networks have migrated to ISIS for intradomain ip routing. I think these are also good opportunities for us to consider how we want to manage topology distribution in the futre rather than just blindly adopting what was defined In the past for ip networks. So it seems to me we ought to discuss and understand the fundamental process that we want to see occur before we decide what the proper mechanism is to accomplish that process. Perhaps we should review the NSI requirements for topology distribution...I dont think we ever actually came up with one that was vetted by the group...I made some bullets that were presented at OGF in Lyon, but those were just talking points and i think were oriented more to topology representation rathe rthan distribution and discovery processes. thoughts? jerry Sent from my iPad3g On May 29, 2012, at 7:14 AM, Jeroen van der Ham <vdham@uva.nl> 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.
Hot dang, a heated debate. I thought everyone had fallen into a volcano while in Iceland. I nearly swallowed my tongue when I read OSPF. I was hoping for something extremely simple that would just allow me to query a peer and control the retrieval of what they know. Something very similar in concept to a protocol like LDAP where I can list the top level branches of the tree (available networks), then do a detailed retrieval of the contents of a subtree (topology for the network). I would also like to put a watcher on a subtree to be notified when anything was updated. I am definitely big on reuse, but if my aging memory serves me correctly, the last time I implemented OSPF in a product it was not a trivial task. I need a bit more of trivial these days ;-) Nice to see everyone is back. I hope the conference went well. John. On 2012-05-29, at 9:45 AM, Jerry Sobieski wrote:
This bootstrapping process is exactly what I described: How do you learn what the world looks like topologically when the NSA starts up? And how do you do this in a global distributed system of autonomous administrative domains and millions of untrusted [topology] consumers?
the problem with OSPF is that it indeed floods link state announements. But this is a scaling problem in a large multidomain environments and can take a significant time for such protocols to converge..if ever they ever do. And even with OSPF not all toplogy is expressed...there are summarized LSA and areas...etc. all these hide topology in an attempt to make it scale better.
and ospf is non trivial... It does not use IP. It has no authorization security either. And it is not exactly a web service:-). it has multiple timers just to tell when a neighbor is present and how/when to flood link state announcements. yet no way to determine if a LSA is to be trusted. And you still need to discover or configure the local topology...ospf can only do this in very limited cases...even in gmpls this was done by LMP...yet another protocol. further, the topology technologies/layering are defined in the protocol, rather than a separate topology standard...thus you need to change the protocol in order to enhance the topology descriptions. And the open source implementations (quaga, zebra, ...) are not small packages easily modified...
These are some of the reasons why you never see OSPF in interdomain use. And rarely see it even in multilayer use. And why many networks have migrated to ISIS for intradomain ip routing. I think these are also good opportunities for us to consider how we want to manage topology distribution in the futre rather than just blindly adopting what was defined In the past for ip networks.
So it seems to me we ought to discuss and understand the fundamental process that we want to see occur before we decide what the proper mechanism is to accomplish that process.
Perhaps we should review the NSI requirements for topology distribution...I dont think we ever actually came up with one that was vetted by the group...I made some bullets that were presented at OGF in Lyon, but those were just talking points and i think were oriented more to topology representation rathe rthan distribution and discovery processes.
thoughts? jerry
Sent from my iPad3g
On May 29, 2012, at 7:14 AM, Jeroen van der Ham <vdham@uva.nl> 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.
Hi, On 29 May 2012, at 16:22, John MacAuley wrote:
Hot dang, a heated debate. I thought everyone had fallen into a volcano while in Iceland.
Some of the fire from the volcanoes spurred us back to the debate indeed ;)
I nearly swallowed my tongue when I read OSPF. I was hoping for something extremely simple that would just allow me to query a peer and control the retrieval of what they know. Something very similar in concept to a protocol like LDAP where I can list the top level branches of the tree (available networks), then do a detailed retrieval of the contents of a subtree (topology for the network). I would also like to put a watcher on a subtree to be notified when anything was updated.
I have no close experience with LDAP, how does it work with multiple distributed sources of information? What about the subtree notifications?
I am definitely big on reuse, but if my aging memory serves me correctly, the last time I implemented OSPF in a product it was not a trivial task. I need a bit more of trivial these days ;-)
I indeed meant an OSPF-like protocol. It may not be trivial, but it's a proven technology. It has some great extensibility features using the TLV fields. If that's off the table, we could of course also look into peer-to-peer like systems. There is some great work on distributed storage using distributed hash tables (DHT) that may also be applicable to this situation. Jeroen.
Hi, Regarding LDAP - it does not scale. It's just simple tree structure, not a graph so we can’t model too much with that. Never heard of any mechanisms for distributed maintenance. IMHO - Pro: easy to implement, Cons: all the rest. Best regards Radek ___________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and Networking Center radek.krzywania@man.poznan.pl +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 Behalf Of Jeroen van der Ham Sent: Wednesday, May 30, 2012 11:59 AM To: John MacAuley Cc: NSI WG Subject: Re: [Nsi-wg] Topology section
Hi,
On 29 May 2012, at 16:22, John MacAuley wrote:
Hot dang, a heated debate. I thought everyone had fallen into a volcano while in Iceland.
Some of the fire from the volcanoes spurred us back to the debate indeed ;)
I nearly swallowed my tongue when I read OSPF. I was hoping for something extremely simple that would just allow me to query a peer and control the retrieval of what they know. Something very similar in concept to a protocol like LDAP where I can list the top level branches of the tree (available networks), then do a detailed retrieval of the contents of a subtree (topology for the network). I would also like to put a watcher on a subtree to be notified when anything was updated.
I have no close experience with LDAP, how does it work with multiple distributed sources of information? What about the subtree notifications?
I am definitely big on reuse, but if my aging memory serves me correctly, the last time I implemented OSPF in a product it was not a trivial task. I need a bit more of trivial these days ;-)
I indeed meant an OSPF-like protocol. It may not be trivial, but it's a proven technology. It has some great extensibility features using the TLV fields.
If that's off the table, we could of course also look into peer-to-peer like systems. There is some great work on distributed storage using distributed hash tables (DHT) that may also be applicable to this situation.
Jeroen.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
I didn't literally mean the LDAP protocol itself, although, I would definitely argue the "it does not scale" argument. I was trying to relate a simple interface similar to LDAP (which is a stripped down version of X.500) that would allow me to query a peer's view of the topological world. In addition, through simple notifications I could be told when changes have occurred on topologies of interest. I like Jeroen's P2P angle. I did a lot of work with the peer discovery mechanisms back when bit torrent first came out as a way to reduce tracker load. The concepts of nodes and super nodes to distribute topology is a cool idea, but we have a restricted peering model that would prevent any random NSA from communicating with any other random NSA. Of course, we could decide to change our model to more of a P2P relationship and what the sysadmin's across the world have heart attacks ;-) John On 2012-05-30, at 6:42 AM, Radek Krzywania wrote:
Hi, Regarding LDAP - it does not scale. It's just simple tree structure, not a graph so we can’t model too much with that. Never heard of any mechanisms for distributed maintenance. IMHO - Pro: easy to implement, Cons: all the rest.
Best regards Radek
___________________________________ Radoslaw Krzywania
Network Research and Development Poznan Supercomputing and Networking Center
radek.krzywania@man.poznan.pl +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 Behalf Of Jeroen van der Ham Sent: Wednesday, May 30, 2012 11:59 AM To: John MacAuley Cc: NSI WG Subject: Re: [Nsi-wg] Topology section
Hi,
On 29 May 2012, at 16:22, John MacAuley wrote:
Hot dang, a heated debate. I thought everyone had fallen into a volcano while in Iceland.
Some of the fire from the volcanoes spurred us back to the debate indeed ;)
I nearly swallowed my tongue when I read OSPF. I was hoping for something extremely simple that would just allow me to query a peer and control the retrieval of what they know. Something very similar in concept to a protocol like LDAP where I can list the top level branches of the tree (available networks), then do a detailed retrieval of the contents of a subtree (topology for the network). I would also like to put a watcher on a subtree to be notified when anything was updated.
I have no close experience with LDAP, how does it work with multiple distributed sources of information? What about the subtree notifications?
I am definitely big on reuse, but if my aging memory serves me correctly, the last time I implemented OSPF in a product it was not a trivial task. I need a bit more of trivial these days ;-)
I indeed meant an OSPF-like protocol. It may not be trivial, but it's a proven technology. It has some great extensibility features using the TLV fields.
If that's off the table, we could of course also look into peer-to-peer like systems. There is some great work on distributed storage using distributed hash tables (DHT) that may also be applicable to this situation.
Jeroen.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi, Regarding LDAP - it does not scale. It's just simple tree structure, not a graph so we can’t model too much with that. Never heard of any mechanisms for distributed maintenance. IMHO - Pro: easy to implement, Cons: all the rest. Best regards Radek ___________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and Networking Center radek.krzywania@man.poznan.pl +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 Behalf Of Jeroen van der Ham Sent: Wednesday, May 30, 2012 11:59 AM To: John MacAuley Cc: NSI WG Subject: Re: [Nsi-wg] Topology section
Hi,
On 29 May 2012, at 16:22, John MacAuley wrote:
Hot dang, a heated debate. I thought everyone had fallen into a volcano while in Iceland.
Some of the fire from the volcanoes spurred us back to the debate indeed ;)
I nearly swallowed my tongue when I read OSPF. I was hoping for something extremely simple that would just allow me to query a peer and control the retrieval of what they know. Something very similar in concept to a protocol like LDAP where I can list the top level branches of the tree (available networks), then do a detailed retrieval of the contents of a subtree (topology for the network). I would also like to put a watcher on a subtree to be notified when anything was updated.
I have no close experience with LDAP, how does it work with multiple distributed sources of information? What about the subtree notifications?
I am definitely big on reuse, but if my aging memory serves me correctly, the last time I implemented OSPF in a product it was not a trivial task. I need a bit more of trivial these days ;-)
I indeed meant an OSPF-like protocol. It may not be trivial, but it's a proven technology. It has some great extensibility features using the TLV fields.
If that's off the table, we could of course also look into peer-to-peer like systems. There is some great work on distributed storage using distributed hash tables (DHT) that may also be applicable to this situation.
Jeroen.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi, I think Jeroen was thinking on OSPF mechanisms, not the OSPF itself (at least I did). So use the algorithms and behaviour but adopted to our needs. We can use Web Services for that and introduce security. It's up to us. We don’t need to use Quagga or whatever other routing software for that purpose. 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 Behalf Of Jerry Sobieski Sent: Tuesday, May 29, 2012 3:45 PM To: Jeroen van der Ham Cc: NSI WG Subject: Re: [Nsi-wg] Topology section
This bootstrapping process is exactly what I described: How do you learn what the world looks like topologically when the NSA starts up? And how do you do this in a global distributed system of autonomous administrative domains and millions of untrusted [topology] consumers?
the problem with OSPF is that it indeed floods link state announements. But this is a scaling problem in a large multidomain environments and can take a significant time for such protocols to converge..if ever they ever do. And even with OSPF not all toplogy is expressed...there are summarized LSA and areas...etc. all these hide topology in an attempt to make it scale better.
and ospf is non trivial... It does not use IP. It has no authorization security either. And it is not exactly a web service:-). it has multiple timers just to tell when a neighbor is present and how/when to flood link state announcements. yet no way to determine if a LSA is to be trusted. And you still need to discover or configure the local topology...ospf can only do this in very limited cases...even in gmpls this was done by LMP...yet another protocol. further, the topology technologies/layering are defined in the protocol, rather than a separate topology standard...thus you need to change the protocol in order to enhance the topology descriptions. And the open source implementations (quaga, zebra, ...) are not small packages easily modified...
These are some of the reasons why you never see OSPF in interdomain use. And rarely see it even in multilayer use. And why many networks have migrated to ISIS for intradomain ip routing. I think these are also good opportunities for us to consider how we want to manage topology distribution in the futre rather than just blindly adopting what was defined In the past for ip networks.
So it seems to me we ought to discuss and understand the fundamental process that we want to see occur before we decide what the proper mechanism is to accomplish that process.
Perhaps we should review the NSI requirements for topology distribution...I dont think we ever actually came up with one that was vetted by the group...I made some bullets that were presented at OGF in Lyon, but those were just talking points and i think were oriented more to topology representation rathe rthan distribution and discovery processes.
thoughts? jerry
Sent from my iPad3g
On May 29, 2012, at 7:14 AM, Jeroen van der Ham <vdham@uva.nl> 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
Hi, I think Jeroen was thinking on OSPF mechanisms, not the OSPF itself (at least I did). So use the algorithms and behaviour but adopted to our needs. We can use Web Services for that and introduce security. It's up to us. We don’t need to use Quagga or whatever other routing software for that purpose. Fair enough... But it still comes down to "what do we want it to do?" We have on several occasions looked at using OSPF routing
On 5/29/12 10:26 AM, Radek Krzywania wrote: protocol (and GMPLS variants) only to decide that it would not work well in inter-domain environment for a number of architectural reasons never mind the shift from XML based data descriptions to TLVs. I do agree we should consider the aspects of OSPF style flooding. But even so it is a non-trivial implementation. May I suggest the following topology exchange process: 1) Bootstrap: Lets assume that each NSA is initialized with a local topology. This initial topology is likely a manually specified "local" topology (e.g. the RDF/OWL we use now.) Assume this topology is announced via a public "topology URL". Further, assert that the topology description contains SDPs that reference the topology URLs of the adjacent networks. 2) Given this initial info, an agent/NSA would "pull" information from each URL referenced in the SDPs, iteratively fetching each new topology URL as they are encountered. The topology information from each remote topology URL is merged with the local topology to create a comprehensive "world view". This is simple, but poses the N^2 scaling problem: all NSAs contact all other NSAs. This is addressed as follows: 3) As each NSA merges another topology file into their world view topology, they post that merged world view to the topology URL for the local domain. (Thus the local advertized topology includes both local topology and other topology the NSA now knows about the world.) 4) An NSA only explores (fetches) "hanging" SDPs. Hanging SDPs have not had their topology URL fetched and merged into the world view. 5) Finally, each NSA periodically refreshes its world view. _/But/_ because the topology URLs are providing _/world view/_ topology (not just local topology), an NSA only needs to fetch the topology from immediate neighbor(s) to get updated world views. Thus addressing the N^2 problem and updates propagate to all topology agents I think this process is exceedingly simple - it essentially only requires a periodic HTTP GET of topology from one (or a few) URLs. An NSA can still directly walk the entire global topology itself if it desires, but it is not necessary - it need only fetch topology from its immediate neighbors. Updates will flood (propagate) out as a result of periodic refresh. Thus, topology will converge with time. A nice feature of this proposed process is that it allows for NSAs to act as a topology servers. An agent/NSA could walk the topology from any starting domain and construct a world view. And this same server could continuously monitor these domains for updates. Clients or other NSAs can fetch the world view from the topology server first. Such a server effectively reduces the diameter of the propagation domain thus allowing the topology to converge quicker. The process allows multiple [redundant] servers to exist. One concern I had with this process is the update propagation mechanism - it is based on periodic pull rather than an event driven push. A push is only useful if the time between update events is large - propagating updates as they occur rather than waiting for some periodic schedule. If, however, updates are happening frequently, then a periodic pull is just as effective as a push, maybe more so if it allows updates to be batched. Given the complexity we have seen due to firwalls and NATs, I think the complexity of a push mechanism is more sophisticated tahn we need for now - and we have our hands full getting CS v2.0 code working as it is. _So, for now, I believe a periodic pull will be fine and so simple as to be trivial._ Further, a pull allows an NSA to selectively pull updates only from particular key other networks, or from just particular other servers. I.e. a hierarchichal server tree could be constructed (ala DNS.) One aspect that still needs some discussion is the "merge" process. A sophisticated validation processes will be challenging (shelve this for now). I also think an intelligent update of a topology by construct elements will be non-trivial (shelve this for now). I suggest we keep it simple: a merge simply uses the latest known version of a domain's topology. We just wholesale replace a domain's topology text with the most current version of the text file in its entirety. Not a surgical strike, but should work for near future. We simply need a topology construct that timestamps the topology file. We could also define expiration date element as well - thus telling other NSAs how often they should refresh. Thoughts? J
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 Behalf Of Jerry Sobieski Sent: Tuesday, May 29, 2012 3:45 PM To: Jeroen van der Ham Cc: NSI WG Subject: Re: [Nsi-wg] Topology section
This bootstrapping process is exactly what I described: How do you learn what the world looks like topologically when the NSA starts up? And how do you do this in a global distributed system of autonomous administrative domains and millions of untrusted [topology] consumers?
the problem with OSPF is that it indeed floods link state announements. But this is a scaling problem in a large multidomain environments and can take a significant time for such protocols to converge..if ever they ever do. And even with OSPF not all toplogy is expressed...there are summarized LSA and areas...etc. all these hide topology in an attempt to make it scale better.
and ospf is non trivial... It does not use IP. It has no authorization security either. And it is not exactly a web service:-). it has multiple timers just to tell when a neighbor is present and how/when to flood link state announcements. yet no way to determine if a LSA is to be trusted. And you still need to discover or configure the local topology...ospf can only do this in very limited cases...even in gmpls this was done by LMP...yet another protocol. further, the topology technologies/layering are defined in the protocol, rather than a separate topology standard...thus you need to change the protocol in order to enhance the topology descriptions. And the open source implementations (quaga, zebra, ...) are not small packages easily modified...
These are some of the reasons why you never see OSPF in interdomain use. And rarely see it even in multilayer use. And why many networks have migrated to ISIS for intradomain ip routing. I think these are also good opportunities for us to consider how we want to manage topology distribution in the futre rather than just blindly adopting what was defined In the past for ip networks.
So it seems to me we ought to discuss and understand the fundamental process that we want to see occur before we decide what the proper mechanism is to accomplish that process.
Perhaps we should review the NSI requirements for topology distribution...I dont think we ever actually came up with one that was vetted by the group...I made some bullets that were presented at OGF in Lyon, but those were just talking points and i think were oriented more to topology representation rathe rthan distribution and discovery processes.
thoughts? jerry
Sent from my iPad3g
On May 29, 2012, at 7:14 AM, Jeroen van der Ham<vdham@uva.nl> 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
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 <http://bit.ly/bisCAd> Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3><http://bit.ly/d2Olql>
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 <http://bit.ly/bisCAd> Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3><http://bit.ly/d2Olql>
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@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@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/
Hi, In AutoBAHN the lookup service is rather to find STPs and neighbour agents, not the topology. The topology is built by receiving topology updates from neighbours. TimeToLive may be useful to have in NSI. 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 5:07 PM To: radek.krzywania@man.poznan.pl Cc: 'Jeroen van der Ham'; 'NSI WG' Subject: Re: [Nsi-wg] Topology section
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
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
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
NSA list 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
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 list of 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
HI John- See comments/thoughts in line- On 5/15/12 10:20 PM, John MacAuley wrote:
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. With the current NSI topology, all we really have is the adjacencies. The SDPs. So walking the topology outward will only return adjacencies. This *will* provide the 1st level approximation for path finding. "Detailed topology" begs the question of what details do you want / not want? How do you know which details you need?
How does this all scale? If an NSA begins by asking direct peers for their peers, and then asks those NSAs for their peers (less NSAs already visited), etc. If you do not walk the whole network, you will not discover all adjacencies. So, at least once at initialization, an NSA needs to walk the whole topology. And we still need to flood updates somehow - but the importance of updates is dependent on the type of information you want updated (e.g. link state (slow) vs link utilization (fast)). Also, this walking method might be optimized if you also asked for reachability as well as direct peers as this will tell you if a transit NSA is "of interest" to a particular request...but I hope you don't plan to walk the entire topology for every request...that will definately be a scaling problem. Also, this mechanism means that NSAs would in general need to be responsive to all requests for topology regardless of the origin... Not every network will see this as a function they will want to perform... If the number of NSAs gets large, walking the entire topo could find ourselves handling peer requests for quite a few NSAs that we do not have direct peerings with... Considering that any user NSA could be walking the topology as they do path finding this walking method to discover topology could be quite onerous on core NSAs. An alternative is to ask direct peers only but for their /entire/ worldview. This restricts topology exchange to only direct peers. However, Since we are getting the entire worldview, we don't actually need to fetch it from a direct peer. Indeed, we could fetch it from *any* single NSA willing to talk to us. I.e. in this scenario we could have one or more NSAs that act solely as topology servers, these could be a few strategically placed, or could be many self selected, but the exchange process is *much* reduced - or at least concentrated on these topo servers. In this scenario an NSA is manually configured with one or more topology server NSAs. The local NSA simply queries one or more of those servers on startup to get a worldview. This scenario also supports a reasonably simple update mechanism... When an NSA requests a worldview, it could also indicates if it wants a push of updates from server to client, or if it will pull updates when needed. It the client can also act as a server to the "server" - i.e. the server can ask the client to push updates or indicate it will periodically pull updates to the server. Same protocol both ways. There are still some nuances to be addressed, but these are protcol issues, not structural scaling issues. While walking the tree seems simple, it doesn't scale so well in my estimation. The server style (IMO) can be fairly simply implemented to start (i.e. a single topo server NSA) and can expand easily as necessary. Indeed, every NSA could be a server to only specific other clients...a sort of self organizing distribution tree. I think this will scale much better. In any case, we do need some [simple] protocol for managing the topology exchange. I.e. we need to define the topo representation format, some sort of timestamp to age the topo information, a mechanism for indicating push/pull preference for updates, what ypes of updates we want, and for a push process a means to accept the push, and for pull a means to request an update rather than full dump, etc. While I think we *should* do this, I don't think this is strictly necessary for V2.0 - Topology distribution is separate from the CS v2.0 features. Perhaps this is where we introduce an NSI TS (Topo Service). We can continue to use a single common worldview file to feed the NSI-CS path finding for now, and make the auto discovery and dynamic updating of that worldview topoDB a separate issue.
2. We will need a subscription mechanism for an NSA to register with a 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. There are two issues here: 1) transitive announcements, and 2) coherency.
The first is an ancient problem: How do I tell you a secret and make sure you do not tell someone else? I simply need to trust you. But there is no real way for me to insure that the information does not get distributed accidentally or otherwise. If the information I give you is sensititve, what is the risk if it is announced wider? For our purposes, unless we have a particular urgent use case, I would push this out for later worry. For now we adopt a simple "all topo announcements are public" rubric. The 2nd issue says: If I learn topology from two different sources, and they are not the same...which should I use? one? or the other? both? How do we merge them into a single valid topoDB? I think this is entirely tractable, but it would be nice, at least for now, we did not have to deal with incoherent topology announcements. So I suggest we do a simple thing now - a single topology server with a single topology worldview. A related issue is timing of updates- Even if topology updates are monolithic when they converge, there will be a period of time when different NSAs will have different worldviews. While this may lead to some failed reservations, I don't think this exposes any flaw in the protocol. The protocol will continue to work properly. My thoughts only... Jerry
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-cnPOrqDkspoRBaTKVVrrldURu...
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
participants (6)
-
Aaron Brown -
Inder Monga -
Jeroen van der Ham -
Jerry Sobieski -
John MacAuley -
Radek Krzywania