Hi Henk, Sorry for the delayed reply on this.
Paul Francis, Ramesh Govindan, and I wrote this draft for setting up a BGP Lab combining the RIPE beacons with other beacons. Please see the attachment for more details. Basically, we would like to allow programmable access to the beacons for researchers, so that it is easier to perform experiments. We plan to provide the software to enable such access.
1) How many users do you expect for this facility: 1, 10, 100, 1000? O(1) is fine, O(10) doable, O(100) will require a major administrative effort from somebody.
I think O(10) is our initial goal. I understand your concern of scaling it to O(100). But for now, if we can have five or six researchers able to share the BGP lab infrastructure, that would be great!
2) Our route collectors are there to collect routes, in order to get the data for the tools that our users use (myASn, BGPlay, all the queries). That's the number 1 priority for them, everything else (including the beacons) is a by-product. The problem with giving out accounts and have people configure their own prefix, is that people can misconfigure things. If this results in a lot of BGP activity, then this will cause people to loose confidence in the RIS project and perhaps even dropping peering sessions. That is a bad thing.
So-far, we have never given any account to anybody, except for own operations, so we can control what is running on the box. This proposal would change that completely.
I understand your concern. One way to ensure that the beacon experiments will not affect the collection of routes and other important operations is by restricting the software that controls the route injection. We can impose the control by rate-limiting how often the beacon prefix can be changed, what type of announcement is allowed. I believe we can accommodate all your concerns by restricting the type and frequency of the operations performed by the users of the bgp lab.
3) We have quagga running on the box to collect and announce routes, you have your own software. I'm not sure if they can coexist (but we can find out).
I believe we can develop the software to ensure that it does not affect the operation of Quagga.
4) Address blocks: the RIR's all have a policy for temporary address assignments. I'm not sure, but I don't think that they allow us to have a large number of used /24's on the shelf. As far as I can see, these policies do not allow for temporary AS# assignments, this might be an oversight, but fixing it will take time.
Bottom line: I like the concept but it will need a lot of thought regarding the practical implications.
Yes, I agree. Perhaps the best way to move forward is to have a conference call to discuss these concerns? Paul and Ramesh, would you be interested in joining the call? Thanks! --Morley
(Cc'ing some of my colleagues, who may want to add something).
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 ------------------------------------------------------------------------------
In a room with a window in the corner, I found truth. (Ian Curtis)