Proposal: do multicast testing on TTM boxes

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