[tt-tf] Fwd: Re: TTM Service 2007 - 2009
Henk Uijterwaal henk at ripe.net
Tue Sep 26 12:11:50 CEST 2006
>X-Original-To: henk at ripe.net >Delivered-To: henk at ripe.net >Date: Tue, 26 Sep 2006 10:07:18 +0100 >From: Brian Nisbet <brian.nisbet at heanet.ie> >User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) >X-Accept-Language: en-us, en >To: Henk Uijterwaal <henk at 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 at 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 TB’s 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 at 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.
[ Tt-tf Archives ]