You are here: Home > Participate > Join a Discussion > Mailman Archives

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