X-Original-To: henk@ripe.net Delivered-To: henk@ripe.net Date: Tue, 26 Sep 2006 10:07:18 +0100 From: Brian Nisbet <brian.nisbet@heanet.ie> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en To: Henk Uijterwaal <henk@ripe.net> Subject: Re: TTM Service 2007 - 2009 X-Enigmail-Version: 0.92.0.0 X-RIPE-Spam-Level: X-RIPE-Spam-Tests: BAYES_00 X-RIPE-Spam-Status: U 0.285436 / -2.6 X-RIPE-Signature: 20a856a8701b575655ec0799ed4b09ee
Henk,
I tried to send this to tt-tf@ripe.net but it was bounced.
Please see below. For discussion,
I don't have a huge amount to add to this as, in general, I agree with it all, but there are a couple of points I'd like to note.
Draft proposal for the TTM service 2007-2009.
Services on the boxes: Starting with the current set of boxes and services: * Delay/Loss/Jitter/Traceroute: At RIPE52, there was clear interest in the data. We propose to continue these measurements. The software on the TBs exists as well as the code to analyze it. We do want to make a couple of adjustments * OWAMP will be added as a method to do measurements on demand, either between TBs or outside the TTM network (subject to access restrictions).
That makes perfect sense and should widen the appeal.
* Data will be collected at a central point and initial processing will still be done. However, we will reduce the number of plots and lists produced by default on a daily basis to something like: daily plots, daily overviews, weekly overviews. All other plots will only be generated on demand. This will result in a bit of lag when one asks for a plot. On the other hand, producing a large number of plots that nobody ever looks at is not a good idea either.
As one of those who pointed out we were still using the data that should satisfy our needs. We very rarely use the box as an up to the second resourse, so some delay for a more detailed plot is fine. I would guess, however I wouldn't want to presume, that other operators act in similiar ways.
* Network alarms will be revisited, is anybody ever looking at them?
I know I haven't looked in quite a while, but as Mike Norris used to use them a lot I will check with him, however I suspect you are right that their readership is extremely low. Is the overhead of generation all that high?
* Data will continue to be visible on the TB itself. * We will set up a DQM mechanism, with a daily routine to look at the data and see if the plots make sense (rather than what we do today: are they being filled).
Both great.
* DNSMON * DNSMON is a valuable service and we will keep it. Features to be added could include: * IPv6 * Trends/Alarms
Excellent.
See below. * New: Protocol beacons * The boxes will start to run protocol beacons, i.e. something that sends out packets for a service on a regular basis, allowing people to monitor their systems. * An example is the multicast work. Another example are the debogon prefixes on the RIS.
Ah, this would be excellent and a welcome service, primarily because it would allow us to maintain one fewer server ourselves and we're always happy if we can manage that.
* New: Network experiments. * We will set up shell accounts that will allow interested parties to do one-off network experiments. (Proposal, measurement, analysis, publication).
Excellent, assuming the necessary strict controls etc.
* New: CBM reference point/server: the boxes will be set up such that interested ISPs can use them for this purpose. The box will offer the configuration site, plus a target for the measurements. The NCC will look into aggregation of data, from reports for one user, to a report for one ISP.
While being broadly in favour of this I still feel we need to be extremely careful about how and to whom this data will be accessible. I think it could be an extremely useful resource for all concered, but also a potential way of making some ISPs (unfairly) angry at RIPE.
Ownership of the boxes: * For both TTM and DNSMON, it is essential that there are a large number of active TTM boxes at interesting locations. * For this reason, the NCC proposes to install a number of boxes at important locations for free. The NCC pays for the hardware and service contract, the local site only for power/connectivity/operations (making it essentially free). Rough criteria for hosting a box:
This is a fantastic idea and one that I am very glad to see.
Roughly how many boxes would be expected to be deployed under this scheme?
Hardware: Outdated hardware, hardware without a current contact person, etc, is an ongoing concern for our operations people. We suggest the following changes: * We start writing off the hardware, say 3 or 4 years (perhaps longer for the clocks). After this period, a box will be automatically switched off unless a site buys new hardware.
When you say 'new' hardware, are you talking about a new model of the same box (which may be difficult when it comes to Dell 350s?) or is the server base for the TTM box being upgraded? And if so, to what?
* We will start to support GPS-free boxes (TSC clock) once that technology is mature. A nearby Stratum-1 NTP server may be required.
Considering the problems I'm currently having getting the antenna for TT-35 to play nice, this is encouraging. I strongly suspect HEAnet will continue to want a Stratum-1 clock on our box, but anything that can be done to make installation easier for the majority is a good thing.
Administrative: Our finance department faces a lot of problems collecting the service fee. It is often not clear to people that the SF is an integral part of the service. Also collecting money from hosts where the contact people have disappeared. We suggest: * The current service contracts will be revisited and replaced (taking into account the text of the current contract) by a new contract. * In the new system, there will be one contract to cover: * Hardware * Service fee for a 3 year period * Shipping, import/export duties, The host has to pay the entire sum at once, in advance. After that, there will be no hidden fees.
Ah yes, most useful. Is there any fear that a higher price will put people off?
* Sites will be asked to provide current contact information and to regularly check this.
Is the intention for the site to check this or for the RIPE NCC to prompt the site to check this?
Lifetime of this proposal: This is a 3-year plan, 2007-2009, to be evaluated afterwards.
Overally I think this is an excellent plan and, on what is given here, I believe it will maintain those parts of the service that Gert and I were so forthright about in Istanbul while providing a model to stabilise and then expand the network.
Thanks,
Brian.
-- Brian Nisbet, Senior Network Engineer, HEAnet Email: brian.nisbet@heanet.ie Tel: +35316609040/Fax:+35316603666
------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000.