Multicast Monitoring on RIPE NCC Test Traffic Boxes
I propose to add testing of multicast connectivity between the RIPE NCC Test Traffic 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 already exist).
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 Autonomous System (AS), or in between).
a. Arguments supporting the proposal:
The RIPE NCC Test Traffic boxes form a very useful measurement platform, distributed over a large number of provider networks.
IP Multicast monitoring is inherently difficult, as you cannot 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 NCC Test Traffic 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.