Sorry, forgot to include ris-int. /Matthew
-----Original Message----- From: Matthew Williams [mailto:matthew@ripe.net] Sent: 29 September 2004 16:05 To: zmao@eecs.umich.edu Cc: beacons@ripe.net Subject: RE: [ris-int] RIS Beacons
Hi again,
The old beacons list has been revitalised with the additions of Shane, Paul and Ramesh. The more, the merrier ;)
Bush), we are performing this experiment (shown http://www.psg.com/~zmao/beacon5.jpg) to understand the effect of fail over behavior. Perhaps something similar to this can be set up in the RIS beacon project. This would be very interesting to study.
Wow, quite an intricate little beacon. In principle, once we have the appropriate set up with transit providers (and they understand what we're doing), then we should be able to oblige. The question, however, is how to prioritise among many experiments and find the RIPE NCC resources to support them. The RIS team will probably have to discuss this internally before providing answers.
Perhaps a similar scheme to the PSG beacons can be adopted. Right now, for PSG beacons we are overloading the Aggregator
Sorry, I forgot that James had actually implemented above.
+++
Since 12th September 2003
All beacon prefixes are now announced with additional attributes. We now overload the BGP AGGREGATOR attribute to tag each announcement with a timestamp, a sequence number and the identifier of the RRC making the announcement. These are encoded as follows....
http://www.ripe.net/ris/beaconlist.html
+++
This seems similar to PSG's schema, no?
I believe that you use your own beacon code, while we still use Quagga. Where there any special reasons for this or was Quagga just to heavy-weight for beacon purposes? Moreover, some concerns were raised about 'lag' between execution of the cron job that modifies the [no] network statement and when the a's or w's actually hit the wire. Is this still an issue or will timestamping be sufficient to deal with it?
Cheers, Matthew
-----Original Message----- From: Z. Morley Mao [mailto:zmao@eecs.umich.edu] Sent: 29 September 2004 06:57 To: Matthew Williams Cc: 'Henk Uijterwaal (RIPE NCC)'; ris-int@ripe.net; 'Shane Kerr'; Ramesh Govindan; Paul Francis Subject: RE: [ris-int] RIS Beacons
Hi Henk and Matthew,
Thanks very much for including me on these emails. I have also CC'd Ramesh Govindan and Paul Francis who are also interested in using the Beacons.
a) They have more peers giving transit than any other AS on the Internet.
This was discussed internally right from day one of RIS beacon project. Good that the research community have confirmed concerns raised back then.
Would it be possible to set up the experiment such that the beacon alternates across the different upstream providers, i.e., at one point announced by two providers, then withdraw from one, re-announce to another one, etc? And iterate using another two different providers.
For one of the multi-homed PSG beacons (hosted by Randy Bush), we are performing this experiment (shown http://www.psg.com/~zmao/beacon5.jpg) to understand the effect of fail over behavior. Perhaps something similar to this can be set up in the RIS beacon project. This would be very interesting to study.
b) When a prefix is invisible, it is not clear if this
is caused by
an experimental problem or by the prefix being
filtered. The
anchor prefix does not solve this problem, there should
be one anchor
per beacon.
Yup, our beacons were deemed practically useless in the paper by Mao, Bush et al, so it's good that we're finally fixing above.
What about timestamping and sequence numbers in the BGP messages? Was this also something that needed to be addressed?
Perhaps a similar scheme to the PSG beacons can be adopted. Right now, for PSG beacons we are overloading the Aggregator AS field to denote the sequence number (each new announcement has a seq number incremented from the old one), and aggregator IP field to denote the time at which the message is sent out. To prevent people from misinterpreting these two fields, we make sure that the Aggregator AS is in the private AS range (64512-65535), and the Aggregator IP is also in the private address range (e.g., 10/8).
Thanks!
--Morley
Cheers, Matthew
-----Original Message----- From: ris-int-admin@ripe.net [mailto:ris-int-admin@ripe.net] On Behalf Of Shane Kerr Sent: 28 September 2004 12:25 To: Henk Uijterwaal (RIPE NCC) Cc: zmao@eecs.umich.edu; ris-int@ripe.net Subject: Re: [ris-int] RIS Beacons
All,
At SIGCOMM 2004, it became clear that the current beacon prefixes suffer from 2 problems:
a) They have more peers giving transit than any other AS on the Internet.
b) When a prefix is invisible, it is not clear if this is caused by an experimental problem or by the prefix being filtered. The anchor prefix does not solve this problem, there should be one anchor per beacon.
So, people suggested that for the next period (1/10/2004-30/9/2005), we make the following changes:
1. A new /19 is requested from the RIPE NCC. This /19 is split into /24's.
2. Each RRC annouces 2 /24's. Assuming A.B.Z is the
Henk Uijterwaal (RIPE NCC) wrote: base address
A.B.(Z+2*Y).0/24 A.B.(Z+2*Y+1).0/24
For Y=0 to 13 for the (up to 16) RRC's.
The first prefix is announced permanently. The second
prefix: up at 0 GMT, down at 2 GMT, up at 4 GMT etc. The pattern may be changed at a later stage.
3. Inside each /24, a pingable address will be established.
4. We ask only 2 or 3 peers at each IX to provide
one is a flapping transit for these
prefixes. (In other words, we do not ask everybody).
5. Other experiments that we do are:
- An overflow prefix (prefix announced at 1 RRC, flapping at the next). - Hitesh's experiment.
6. The current 195.80.224.0/20 is returned to the RIPE NCC
Comments?
This looks good to me.
-- Shane Kerr RIPE NCC