From henk at ripe.net Tue Oct 4 08:34:12 2005 From: henk at ripe.net (Henk Uijterwaal) Date: Tue, 04 Oct 2005 08:34:12 +0200 Subject: TTWG RIPE 51 Working Group Agenda In-Reply-To: <5.2.1.1.2.20050929175424.04e3e358@mailhost.ripe.net> References: <5.2.1.1.2.20050929175424.04e3e358@mailhost.ripe.net> Message-ID: <6.2.3.4.2.20051004083025.02d6c138@localhost> Dear all, The TT-WG will meet next week during RIPE51, on Wednesday afternoon, 16:00-18:00. Alex Tudor won't be able to make it, so I'll chair the meeting. For the agenda I have, so-far: 1. Administrativia (5') - Scribe - Blue Sheets - Minutes from the previous meeting 2. TTM Status and Plans (RIPE NCC, 10'). 3. Building a solution for active monitoring of the Swedish Internet Rickard Dahlstrand, 25' 4. EGEE Project Loukik Kudarimoti 5. Discussion on the Consumer Broadband Measurements draft 6. AOB If there are any additional topics that you want to bring up, let me know. We still have space on the agenda. Henk ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) From henk at ripe.net Wed Oct 12 13:44:35 2005 From: henk at ripe.net (Henk Uijterwaal) Date: Wed, 12 Oct 2005 13:44:35 +0200 Subject: Consumer Broadband Monitoring Proposal Message-ID: <6.2.3.4.2.20051012133545.02cda6d8@localhost> Dear All, Attached you will find a first draft of a proposal to do Consumer Broadband Monitoring, using some of the TTM infrastructure. This proposal is open for discussion starting from today, comments can be made at the TT-WG session this afternoon or on the tt-wg at ripe.net mailing list. The proposal will enter the RIPE Policy Development Process soon. The first step is a 4 week discussion period of the draft. Henk ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) -------------- next part -------------- A non-text attachment was scrubbed... Name: cbm1.pdf Type: application/pdf Size: 59679 bytes Desc: not available URL: From gert at space.net Fri Oct 28 20:02:12 2005 From: gert at space.net (Gert Doering) Date: Fri, 28 Oct 2005 20:02:12 +0200 Subject: Proposal: do multicast testing on TTM boxes Message-ID: <6.2.3.4.2.20051028200208.0537bbf0@localhost> Hi, as there was some support for the multicast testing on the test boxes, and no strong opposition (besides the philosophical debate "does multicast exist"), I'm now formally proposing to do this, using the PDP process. Gert Doering -- NetMaster --------------------------------------- 1. Number (assigned by the RIPE NCC) 2. Policy Proposal Name: multicast monitoring on test boxes 3. Author a. name: Gert Doering b. e-mail: gert at space.net c. organisation: SpaceNet AG 4. Proposal Version: 1.0 5. Submission Date: 2005-10-29 6. Suggested WG for discussion and publication Test Traffic WG 7. Proposal type: a. new 8. Policy term: a. permanent 9. Summary of proposal I propose to add testing of multicast connectivity between the RIPE test boxes that are connected to multicast-capable networks. The test setup could consist of the following components: - multicast beacons, that send packets in regular intervals to well-known multicast addresses (some beacons exist already) - multicast listeners, that monitor incoming beacon packets, and complain if packets from given senders stop arriving - some high level monitoring infrastructure that can use the data from "lots of beacons and listeners" to figure out *where* the problem is (it *has* to be in *this* or *that* AS, or in between) 10. Policy text (I'm not really sure if there are policy documents that describe what the testboxes do and don't do, but if yes, they should be modified appropriately) 11. Rationale: a. Arguments supporting the proposal The RIPE testboxes form a very useful measurement platform, distributed over a large number of provider networks. IP Multicast monitoring is inherently difficult, as you can't easily probe connectivity from a single point of view - some problems need testing and monitoring from multiple different locations to identify "black holes" on some paths. When troubleshooting connectivity issues spanning multiple networks, things are a lot easier if a neutral entity does the monitoring and pinpointing of problem areas. I think the RIPE testbox network is uniquely qualified to do this. b. Arguments opposing the proposal Some arguments have been brought forward that there are not enough multicast-capable networks to make this a worthwile action. -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234