Topology Distribution document
Hi all, I've uploaded a new version of the Topology Distribution Informational GFD. This document discusses the requirements and possible solutions for the topology distribution for NSI as we have identified them so far. (Note that this is different from the Topology Syntax document which defines the syntax to be used. That is going to be an RP instead of an Informational). The document can be found at https://redmine.ogf.org/dmsf_files/12980?download= Jeroen.
Hi On Wed, 27 Mar 2013, Jeroen van der Ham wrote:
I've uploaded a new version of the Topology Distribution Informational GFD. This document discusses the requirements and possible solutions for the topology distribution for NSI as we have identified them so far.
I've just read the document, and I though it would be standard document, and not so much of a discussion, and this probably reflects in my feedback quit a lot: -- 1.2 The last paragraph: "Requests to NSI"? I am not sure the latter requirement in the sentance is true. 1.3 A lot of these things are specified in the NSI document (also true for 1.2), and I am wondering what they are doing here. It sounds as if NSI is only bi-directional, while it can setup both uni- and bi- directional circuits. 1.4 Initial paragraph is a bit odd. 1.5 The conclusion of this section does not seem to follow the NSI spec or current practice. -- After reading section 1, I am somewhat left wondering what the purpose of the section is. -- 2 Naming the second section introduction is pretty weird. 3.1: I'd relax the phrase "complete seperate" to something like "not necessarely the same" 3.2 The mechanisms described in here are very simple. Yet it sounds quite complicated. 3.3 + 3.4 This sounds more like a discussion than an actual standard. This goes for the entire document, and I find it somewhat problematic. I though the current intention was to switch from the Github approach to an HTTP based distribution. Then later consider a peer-to-peer distribution in time, if neeeded. -- So, what exactly is it we want with this document? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi, On 31 May 2013, at 14:06, Henrik Thostrup Jensen <htj@nordu.net> wrote:
So, what exactly is it we want with this document?
I wrote this document somewhere in the summer of 2012 as an informative report on where things stand, what the requirements are to move forward, and what I see as a roadmap for the future. This came out of a discussion I had with some people at SURFnet and also others. The idea of the document was to put topology distribution on the map for NSI. It is something that we have to do, that we have to think about and it has to happen if we want NSI 2.0 to have any traction at all. Jeroen.
On 31 May 2013, at 14:19, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
On 31 May 2013, at 14:06, Henrik Thostrup Jensen <htj@nordu.net> wrote:
So, what exactly is it we want with this document?
I wrote this document somewhere in the summer of 2012 as an informative report on where things stand, what the requirements are to move forward, and what I see as a roadmap for the future. This came out of a discussion I had with some people at SURFnet and also others.
The idea of the document was to put topology distribution on the map for NSI. It is something that we have to do, that we have to think about and it has to happen if we want NSI 2.0 to have any traction at all.
I should add: this document is meant to be merely informative. It is not a standard, since it does not prescribe or define any specific mechanism. I think it is infeasible to define a standard for topology exchange in time for NSI v2.0. Then again, my expectation last year was that NSI v2.0 would already be published by now, so I could be wrong. Jeroen.
On Fri, 31 May 2013, Jeroen van der Ham wrote:
I should add: this document is meant to be merely informative. It is not a standard, since it does not prescribe or define any specific mechanism.
I think it is infeasible to define a standard for topology exchange in time for NSI v2.0. Then again, my expectation last year was that NSI v2.0 would already be published by now, so I could be wrong.
I think we will need something. But having it out after the CS v2 document is not an inherent problem. In fact, keeping the topology distribution seperate from the CS protocol is probably a good thing. IMO, the HTTP based distribution of topology files is good enough for the immedidate time. It solves the immediate problems of not having network host their own topology and the lack of being able to update it dynamically. It is not a clever, do-all, scale-to-the-moon approach, but those solutions tend to take a lot of time to hash out. Should we write something up on how to do this? I think the document should be fairly small. Essentially there is something like this: 1. Discover Topology URLs from other NSAs discovery service or their topology files. Iterate on this process, until no new networks are found or stop at some defined hop level. 2. Build a topology model from the process in 1. 3. Repeat the process at 1, at some interval - say every other hour - to continously update the topology. For the case of 1000 NSAs, and hourly updates, that is 24000 req/day to serve, or 6.67 req/sec, which is nothing for an HTTP server these days. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (2)
-
Henrik Thostrup Jensen -
Jeroen van der Ham