BGP Lab Vision Statement
--------------------------

Goal:
=====

The goal of the BGP Lab is to allow interested BGP researchers to
perform BGP experiments with unassigned prefixes and observe the
routing and data plane behavior from multiple vantage points.  BGP Lab
will provide "virtual BGP speakers" to individual researchers,
allowing them to independently control the operation of the virtual
BGP speaker and its associated set of prefixes.  In
essence, BGP Lab will be the PlanetLab equivalent for BGP research.
Like PlanetLab, BGP Lab will motivate growth in the size of the
experimental infrastructure, because researchers will see benefit in
donating resources.  Specifically, BGPLab will consolidate the two
largest beacon projects (PSG and RIPE) into a single project to share
resources and promote novel BGP research.

Background:
==========

Both the PSG BGP Beacons project (http://psg.com/~zmao/BGPBeacon.html)
and RIPE Beacons project (http://psg.com/~zmao/BGPBeacon.html)
currently do not allow researchers direct control of their operation.
Rather, each researcher must ask the beacon controllers to do whatever
setup is necessary to run an experiment.  This is a serious
bottleneck, and has resulted in multiple independent beacon projects.
Since many BGP experiments (see below) benefit from having multiple
BGP speakers working together, or from having BGP speakers in
different regions of the globe, this partitioning of beacon projects
detracts from the type and scope of BGP experiments.

The BGP beacons are hosted by various parties primarily in the USA,
while RIPE becaons are hosted at RIPE RIS exchange points, primarily
in Europe.  Most of the RIPE beacons are connected to multiple
upstream providers and simultaneously advertised by all these
providers.

Requirements:
============
Software: 
Current BGP Beacon software is available here:
http://psg.com/~zmao/Software/

The software needs to accommodate flexible control of the prefix
advertisement schedule, type of the update, and update attributes on a
per-peer basis. To allow multiple users to control different prefixes
advertised from the same location, the software can be configured to
control individual prefixes separately.  The software will provide
separation of authority between virtual BGP speakers, e.g., one
researcher may not influence the advertisements of another
researcher's prefixes.  

The software must also impose limitations on each virtual BGP speakers
operation, for instance the frequency of advertisements and the
correctness of the BGP messages.

Towards these ends, BGP Lab software will follow the model of PlanetLab.
That is, the local administrator will have root access for the machines
themselves.  A BGP Lab administrator will have access to the global
parameters of the BGP Lab software itself, and have the ability to
add and delete individual BGP Lab user accounts and set parameters for
each user (i.e. which address prefixes they may use).  The individual BGP
Lab users will have control over a "slice" of the BGP Lab software.
Specifically, they will be able to control BGP parameters associated with
the address prefixes that they have been assigned.

Support from ISPs: 
First, immediate upstream providers must support this effort by
propagating the routing announcements of the Beacon prefixes, which
cannot be aggregated. Ideally, the immediate providers would provide
information on the route flap damping parameter setting on the
internal routers, so that the schedule of the Beacon prefixes are
adjusted accordingly to minimize the probability of route suppression
by flap damping.

It would be very helpful to adjust the import filter policies of the
ISPs as well, so that the attributes of the Beacon prefix are
preserved as much as possible.  For example, oftentimes, ISPs filter
community attributes, which can be used to signal selective
advertisement of the prefixes, especially if the prefix is connected
to multiple upstream providers.

Beyond the first hop immediate ISP, other ISPs also need to accept the
Beacon prefix update and not aggregate the prefixes, so that the
advertisement are globally visible.  Support to allow selective
advertisement is very useful by agreeing on the community attributes
used. 

Support from Address Registries: 
One or more Address Registries (AR) must agree to allocate blocks of
unused prefixes and an AS number to BGP Lab.  The idea is that the
Address Registry would officially still own the addresses and AS
number, and could take them back on very short notice.  An AS number
may not strictly necessary for the Beacon experiments, as the AS
numbers from the sites hosting the beacon prefixes can be used as
origin AS.

Resources:
==========

Address blocks:  unused address blocks are needed for contructing
Beacon prefixes.  Prefixes need to be at least of size /24, otherwise,
they run the risk of being filtered.

Machine with remote log in: at the Beacon hosting site, there needs to
be a machine allowing remote access to control advertisement schedule
and update format.

Machine in the address space of the Beacon prefix: ideally, there
should be a machine within the address space of the Beacon prefix.
This is useful for both debugging purposes (to check if the route to
the prefix is available) and for experiment purposes (e.g., to study
the data plane performance during routing changes).

BGPLab Experiments:
==================

Route Dynamics: The existing beacons are used to study the propagation
of routing updates through the infrastructure. BGPLab would allow larger
scale studies over longer periods of time.

Validating Fault Isolation: Root-cause analysis is an active area of
research, and BGPLab would greatly facilitate the validation of
schemes for proposed techniques.

IP anycast: In order to determine the effects of large scale IP
anycast deployment (for instance to scale and protect root DNS
servers), it must be necessary to dynamically control and coordinate
the IP address blocks advertised from BGP speakers situated in many
locations around the globe.

Quality of aggregation: By inserting controlled combinations of
aggregatable and non-aggregatable prefixes into BGP from various
locations around the globe, we can measure the quality of effect of
BGP aggregation.

BGP operational validation: beacons can be used to understand various
BGP operational behavior. For instance, both operators and researchers
would be interested in understanding the operational effect of setting
various BGP-related parameters (e.g., MinRouteAdvertisementInterval
Timer, Route flap Damping parameters),