Re: Proposal: do multicast testing on TTM boxes
-
From: Gert Doering <>
-
Date: Fri, 28 Oct 2005 10:54:58 +0200
-
Cc: Gert Doering <>
-
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
-
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=nG5OGxEx3dlmOnYZJyrLX/PyOKR2qNFJkquFKy5/jPRTtBjFemvAliPmZywAH4aW ;
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@localhost
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@localhost
Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0
D- 80807 Muenchen Fax : +49-89-32356-234