[tt-tf] Fwd: Re: TTM Service 2007 - 2009

>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.