FW: [ris-int] RIS Beacons
Matthew Williams matthew at ripe.net
Thu Sep 30 13:04:20 CEST 2004
Sorry, forgot to include ris-int. /Matthew > -----Original Message----- > From: Matthew Williams [mailto:matthew at ripe.net] > Sent: 29 September 2004 16:05 > To: zmao at eecs.umich.edu > Cc: beacons at 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 at eecs.umich.edu] > > Sent: 29 September 2004 06:57 > > To: Matthew Williams > > Cc: 'Henk Uijterwaal (RIPE NCC)'; ris-int at 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 at ripe.net [mailto:ris-int-admin at ripe.net] On > > > > Behalf Of Shane Kerr > > > > Sent: 28 September 2004 12:25 > > > > To: Henk Uijterwaal (RIPE NCC) > > > > Cc: zmao at eecs.umich.edu; ris-int at ripe.net > > > > Subject: Re: [ris-int] RIS Beacons > > > > > > > > > > > > Henk Uijterwaal (RIPE NCC) wrote: > > > > > 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 > > 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 > > > > one is a flapping > > > > > 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 > > 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 > > > > > > > > > > >
[ Ris-int Archives ]