From arife at ripe.net Wed Mar 1 15:42:18 2006 From: arife at ripe.net (Arife Vural) Date: Wed, 1 Mar 2006 15:42:18 +0100 Subject: [ris-int] Fw: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <7.0.1.0.2.20060221145012.034f6ae8@ripe.net> References: <200602171340.k1HDeVoR007474@cat.ripe.net> <43F5D554.8010007@ripe.net> <7.0.1.0.2.20060221145012.034f6ae8@ripe.net> Message-ID: <20060301144218.GR31443@ripe.net> > >>I'd like to ask your view on this request. > >>At the moment there are no available beacon prefixes that can be used > >>for this experiment. [...] > > Getting more prefixes should be trivial: walk to RS, ask them for a > temporary assignment for an experiment). > > >>>Set1 (prepending on the link to AS20483) Day1 > >>>A: 00:00 : prepending length =0 > >>>W: 02:00 > >>>A: 04:00 : prepending length=1 > > > >I don't think we can currently do this automatically using the RRCs, > >so it would take a fair bit of manual tinkering to set it up initially. > > That is more of a problem. If we can set this up easily, we should do this. > If not, talk to Shane and see if he has the resources. In any case, we > should reply to the original requestor "soon". Actually, it would be really nice if Lorenzo will pick it up. I will not have time to do it for couple of weeks. Mailing thread is in xrtt. Ticket number is NCC#2006021124. Arife > > Henk > > Henk > > > > >Maybe we could use the same setup that I used for the AS-set > >stuffing experiments, i.e. the BGP announcer and a cron job running > >on a machine with an IBGP peering to the RRCs. > > > >James, what do you think? > > > > > >Cheers, > >Lorenzo > > > >-- > >lorenzo at ripe.net colitti at dia.uniroma3.it > >www.ripe.net www.dia.uniroma3.it/~compunet > >RIPE NCC Roma Tre Computer Networks research group > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ > > 1160438400. Watch this space... > -- Arife Vural SED, RIPE NCC From lorenzo at ripe.net Wed Mar 8 15:46:58 2006 From: lorenzo at ripe.net (Lorenzo Colitti) Date: Wed, 08 Mar 2006 15:46:58 +0100 Subject: [ris-int] Fw: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <20060301144218.GR31443@ripe.net> References: <200602171340.k1HDeVoR007474@cat.ripe.net> <43F5D554.8010007@ripe.net> <7.0.1.0.2.20060221145012.034f6ae8@ripe.net> <20060301144218.GR31443@ripe.net> Message-ID: <440EEE62.7000502@ripe.net> Arife Vural wrote: >> Getting more prefixes should be trivial: walk to RS, ask them for a >> temporary assignment for an experiment). >> >>>>> Set1 (prepending on the link to AS20483) Day1 >>>>> A: 00:00 : prepending length =0 >>>>> W: 02:00 >>>>> A: 04:00 : prepending length=1 >>> I don't think we can currently do this automatically using the RRCs, >>> so it would take a fair bit of manual tinkering to set it up initially. >> That is more of a problem. If we can set this up easily, we should do this. >> If not, talk to Shane and see if he has the resources. In any case, we >> should reply to the original requestor "soon". > > Actually, it would be really nice if Lorenzo will pick it up. I will not > have time to do it for couple of weeks. Ok, so what these guys want to do is see how traffic shifts in different prepending configurations. They have already performed this using another AS (their own?) and they would like to do this from AS12654 as well. This is a reasonable research project, but implementing this on our side is more than a couple of hours of work. I don't really know much about RRC configuration file backups and the like, but it will probably take at least a day or two if we want to do it in any non-hackish manner. And of course whoever does it needs to have operational access to the RRCs. I can try to take care of this, but I'm not sure I'll have time to do this properly before the RIPE meeting. Cheers, Lorenzo -- lorenzo at ripe.net colitti at dia.uniroma3.it www.ripe.net www.dia.uniroma3.it/~compunet RIPE NCC Roma Tre Computer Networks research group From arife at ripe.net Wed Mar 8 15:52:44 2006 From: arife at ripe.net (Arife Vural) Date: Wed, 8 Mar 2006 15:52:44 +0100 Subject: [ris-int] Fw: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <440EEE62.7000502@ripe.net> References: <200602171340.k1HDeVoR007474@cat.ripe.net> <43F5D554.8010007@ripe.net> <7.0.1.0.2.20060221145012.034f6ae8@ripe.net> <20060301144218.GR31443@ripe.net> <440EEE62.7000502@ripe.net> Message-ID: <20060308145244.GT12966@ripe.net> Thanks Lorenzo for the reply. If Henk will have time tomorrow, shall we discuss it tomorrow? Even if we can not make it, it would be nice to tell them. Arife On Wed, Mar 08, 2006 at 03:46:58PM +0100, Lorenzo Colitti wrote: > Arife Vural wrote: > >>Getting more prefixes should be trivial: walk to RS, ask them for a > >>temporary assignment for an experiment). > >> > >>>>>Set1 (prepending on the link to AS20483) Day1 > >>>>>A: 00:00 : prepending length =0 > >>>>>W: 02:00 > >>>>>A: 04:00 : prepending length=1 > >>>I don't think we can currently do this automatically using the RRCs, > >>>so it would take a fair bit of manual tinkering to set it up initially. > >>That is more of a problem. If we can set this up easily, we should do > >>this. > >>If not, talk to Shane and see if he has the resources. In any case, we > >>should reply to the original requestor "soon". > > > >Actually, it would be really nice if Lorenzo will pick it up. I will not > >have time to do it for couple of weeks. > > Ok, so what these guys want to do is see how traffic shifts in different > prepending configurations. They have already performed this using > another AS (their own?) and they would like to do this from AS12654 as well. > > This is a reasonable research project, but implementing this on our side > is more than a couple of hours of work. I don't really know much about > RRC configuration file backups and the like, but it will probably take > at least a day or two if we want to do it in any non-hackish manner. And > of course whoever does it needs to have operational access to the RRCs. > > I can try to take care of this, but I'm not sure I'll have time to do > this properly before the RIPE meeting. > > > Cheers, > Lorenzo > > -- > lorenzo at ripe.net colitti at dia.uniroma3.it > www.ripe.net www.dia.uniroma3.it/~compunet > RIPE NCC Roma Tre Computer Networks research group From henk at ripe.net Thu Mar 9 05:30:29 2006 From: henk at ripe.net (Henk Uijterwaal) Date: Thu, 09 Mar 2006 05:30:29 +0100 Subject: [ris-int] Fw: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <20060308145244.GT12966@ripe.net> References: <200602171340.k1HDeVoR007474@cat.ripe.net> <43F5D554.8010007@ripe.net> <7.0.1.0.2.20060221145012.034f6ae8@ripe.net> <20060301144218.GR31443@ripe.net> <440EEE62.7000502@ripe.net> <20060308145244.GT12966@ripe.net> Message-ID: <7.0.1.0.2.20060309052431.033c4c50@ripe.net> Arife, Lorenzo, >If Henk will have time tomorrow, shall we discuss it tomorrow? No, sorry, I won't. I'm flying back from Brisbane right now, my plan was to stop by the office for 2 hours at most tomorrow, just to say hi to Robert. I then have Thu pm and Friday off. Let's discuss this Monday. Can one of you schedule something? In the meantime, we should send them a "keep-alive" (sorry, we're really busy, we'll look at this next week). Henk >Even if we can not make it, it would be nice to tell them. > >Arife > >On Wed, Mar 08, 2006 at 03:46:58PM +0100, Lorenzo Colitti wrote: > > Arife Vural wrote: > > >>Getting more prefixes should be trivial: walk to RS, ask them for a > > >>temporary assignment for an experiment). > > >> > > >>>>>Set1 (prepending on the link to AS20483) Day1 > > >>>>>A: 00:00 : prepending length =0 > > >>>>>W: 02:00 > > >>>>>A: 04:00 : prepending length=1 > > >>>I don't think we can currently do this automatically using the RRCs, > > >>>so it would take a fair bit of manual tinkering to set it up initially. > > >>That is more of a problem. If we can set this up easily, we should do > > >>this. > > >>If not, talk to Shane and see if he has the resources. In any case, we > > >>should reply to the original requestor "soon". > > > > > >Actually, it would be really nice if Lorenzo will pick it up. I will not > > >have time to do it for couple of weeks. > > > > Ok, so what these guys want to do is see how traffic shifts in different > > prepending configurations. They have already performed this using > > another AS (their own?) and they would like to do this from > AS12654 as well. > > > > This is a reasonable research project, but implementing this on our side > > is more than a couple of hours of work. I don't really know much about > > RRC configuration file backups and the like, but it will probably take > > at least a day or two if we want to do it in any non-hackish manner. And > > of course whoever does it needs to have operational access to the RRCs. > > > > I can try to take care of this, but I'm not sure I'll have time to do > > this properly before the RIPE meeting. > > > > > > Cheers, > > Lorenzo > > > > -- > > lorenzo at ripe.net colitti at dia.uniroma3.it > > www.ripe.net www.dia.uniroma3.it/~compunet > > RIPE NCC Roma Tre Computer Networks research group ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 1160438400. Watch this space... From lorenzo at ripe.net Thu Mar 9 14:53:53 2006 From: lorenzo at ripe.net (Lorenzo Colitti) Date: Thu, 09 Mar 2006 14:53:53 +0100 Subject: [ris-int] Fw: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <7.0.1.0.2.20060309052431.033c4c50@ripe.net> References: <200602171340.k1HDeVoR007474@cat.ripe.net> <43F5D554.8010007@ripe.net> <7.0.1.0.2.20060221145012.034f6ae8@ripe.net> <20060301144218.GR31443@ripe.net> <440EEE62.7000502@ripe.net> <20060308145244.GT12966@ripe.net> <7.0.1.0.2.20060309052431.033c4c50@ripe.net> Message-ID: <44103371.3040704@ripe.net> Henk Uijterwaal wrote: >> If Henk will have time tomorrow, shall we discuss it tomorrow? > > No, sorry, I won't. I'm flying back from Brisbane right now, my > plan was to stop by the office for 2 hours at most tomorrow, just > to say hi to Robert. I then have Thu pm and Friday off. Let's > discuss this Monday. Can one of you schedule something? > > In the meantime, we should send them a "keep-alive" (sorry, we're > really busy, we'll look at this next week). Arife, do you want to do this via xrtt or shall I write up an email and send it? Cheers, Lorenzo -- lorenzo at ripe.net colitti at dia.uniroma3.it www.ripe.net www.dia.uniroma3.it/~compunet RIPE NCC Roma Tre Computer Networks research group From arife at ripe.net Thu Mar 9 14:59:02 2006 From: arife at ripe.net (Arife Vural) Date: Thu, 9 Mar 2006 14:59:02 +0100 Subject: [ris-int] Fw: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <44103371.3040704@ripe.net> References: <200602171340.k1HDeVoR007474@cat.ripe.net> <43F5D554.8010007@ripe.net> <7.0.1.0.2.20060221145012.034f6ae8@ripe.net> <20060301144218.GR31443@ripe.net> <440EEE62.7000502@ripe.net> <20060308145244.GT12966@ripe.net> <7.0.1.0.2.20060309052431.033c4c50@ripe.net> <44103371.3040704@ripe.net> Message-ID: <20060309135902.GJ20624@ripe.net> Hoi Lorenzo, On Thu, Mar 09, 2006 at 02:53:53PM +0100, Lorenzo Colitti wrote: > Henk Uijterwaal wrote: > >>If Henk will have time tomorrow, shall we discuss it tomorrow? > > > >No, sorry, I won't. I'm flying back from Brisbane right now, my > >plan was to stop by the office for 2 hours at most tomorrow, just > >to say hi to Robert. I then have Thu pm and Friday off. Let's > >discuss this Monday. Can one of you schedule something? > > > >In the meantime, we should send them a "keep-alive" (sorry, we're > >really busy, we'll look at this next week). > > Arife, do you want to do this via xrtt or shall I write up an email and > send it? We need the copy of e-mail in xrtt. Please reply the guy, put sw-bugs at ripe.net in CC and also ticket number in Subject line. Thanks. > > > Cheers, > Lorenzo > > -- > lorenzo at ripe.net colitti at dia.uniroma3.it > www.ripe.net www.dia.uniroma3.it/~compunet > RIPE NCC Roma Tre Computer Networks research group > -- Arife Vural SED, RIPE NCC From lorenzo at ripe.net Thu Mar 9 15:50:55 2006 From: lorenzo at ripe.net (Lorenzo Colitti) Date: Thu, 09 Mar 2006 15:50:55 +0100 Subject: [ris-int] Re: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <20060309140336.GK20624@ripe.net> References: <20060309140336.GK20624@ripe.net> Message-ID: <441040CF.9050800@ripe.net> RIS Beacon Request User wrote: > We are studying properties of AS Path Prepending which is > a popular inbound traffic engineering method. We propose an active > measurement method to measure the impact of ASPP method under > different prepending lengths and strategies. > [...] > pattern : We would like prefix to have the following A/W pattern: > Set1 (prepending on the link to AS20483) > Day1 > A: 00:00 : prepending length =0 > W: 02:00 > A: 04:00 : prepending length=1 > W: 06:00 > A: 08:00 : prepending length=2 > W: 10:00 > [...] Dear Samantha, apologies for the delay in replying, we have been busy with other cases. We are discussing this internally and should be able to give you an answer early next week. Regards, Lorenzo -- Lorenzo Colitti lorenzo at ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net From cssmlo at comp.polyu.edu.hk Thu Mar 9 19:18:19 2006 From: cssmlo at comp.polyu.edu.hk (Samantha Lo) Date: Fri, 10 Mar 2006 02:18:19 +0800 Subject: [ris-int] Re: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <441040CF.9050800@ripe.net> References: <20060309140336.GK20624@ripe.net> <441040CF.9050800@ripe.net> Message-ID: <4410716B.9070905@comp.polyu.edu.hk> Dear Lorenzo, Thank you for your kind consideration. We are looking forward to your favorable reply. Best regards, Samantha Lorenzo Colitti said the following on 3/9/2006 10:50 PM: > RIS Beacon Request User wrote: >> We are studying properties of AS Path Prepending which is >> a popular inbound traffic engineering method. We propose an active >> measurement method to measure the impact of ASPP method under >> different prepending lengths and strategies. >> [...] >> pattern : We would like prefix to have the following A/W pattern: >> Set1 (prepending on the link to AS20483) Day1 >> A: 00:00 : prepending length =0 >> W: 02:00 >> A: 04:00 : prepending length=1 >> W: 06:00 A: 08:00 : prepending length=2 >> W: 10:00 >> [...] > > Dear Samantha, > > apologies for the delay in replying, we have been busy with other > cases. We are discussing this internally and should be able to give > you an answer early next week. > > > Regards, > Lorenzo > From wilhelm at ripe.net Fri Mar 10 16:32:24 2006 From: wilhelm at ripe.net (Rene Wilhelm) Date: Fri, 10 Mar 2006 16:32:24 +0100 Subject: [ris-int] RIS Report and Host Spots stats no longer updated ... Message-ID: <20060310153224.296276006B@x27.ripe.net> Hi, It looks like the RIS Reports (IP v4 & v6) pages on http://www.ripe.net/projects/ris/stats/index.html are no longer updated automagically. random picks show *all* graphs on pages like http://www.ris.ripe.net/risreport/rrc03/193.148.15.204/bgpcount.html have a label "(2005-12-04)" which suggests they haven't seen an update since Sinterklaas left the country. Most of these gifs seem to be empty too (any rrc, any peer). Similarly, the last entries on the BGP Hotspots page http://www.ris.ripe.net/topten/ are from Nov 2005. No hyperlinks for Dec 2005, nothing listed for 2006. Can you have a look what's happening? Maybe related to moving the website from Halfweg to the new lama? Cheers, -- Rene From lorenzo at ripe.net Mon Mar 13 14:38:01 2006 From: lorenzo at ripe.net (Lorenzo Colitti) Date: Mon, 13 Mar 2006 14:38:01 +0100 Subject: [ris-int] BGP prepending beacon request Message-ID: <441575B9.1030800@ripe.net> Ok, so here's what we would need to do: 0. Verify that the beacon prefixes 73.0/24 and 89.0/24 are free 1. Send email to them telling them that we will: - Use one RRC (RRC07) - Setup an IBGP peering for them on RRC07 - Relay their announcements - Point them to the software to announce their routes. 2. We ask them to write a short email describing the experiment and their announcement schedule. We tell them that if we don't like it, or if our peers complain, we have to shut the peering down. 3. If they agree, we send out the email to ris-users and our peers on RRC07. If nobody screams, we: - Open firewall for RRC07 if necessary - Configure IBGP peering on RRC07 using the config we already had for my experiments - Set up more detailed filters if necessary - Agree on dates for their experiments 4. On the agreed dates, activate peering 5. When experiment is over, shut down peering Did I miss anything? Cheers, Lorenzo -- Lorenzo Colitti lorenzo at ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net From arife at ripe.net Mon Mar 13 14:56:30 2006 From: arife at ripe.net (Arife Vural) Date: Mon, 13 Mar 2006 14:56:30 +0100 Subject: [ris-int] BGP prepending beacon request In-Reply-To: <441575B9.1030800@ripe.net> References: <441575B9.1030800@ripe.net> Message-ID: <20060313135630.GK18361@ripe.net> That sounds good to me. > Ok, so here's what we would need to do: > > 0. Verify that the beacon prefixes 73.0/24 and 89.0/24 are free They are free. > > 1. Send email to them telling them that we will: > - Use one RRC (RRC07) > - Setup an IBGP peering for them on RRC07 > - Relay their announcements > - Point them to the software to announce their routes. > > 2. We ask them to write a short email describing the experiment and > their announcement schedule. We tell them that if we don't like it, or > if our peers complain, we have to shut the peering down. > > 3. If they agree, we send out the email to ris-users and our peers on > RRC07. If nobody screams, we: > - Open firewall for RRC07 if necessary > - Configure IBGP peering on RRC07 using the config we already had > for my experiments > - Set up more detailed filters if necessary > - Agree on dates for their experiments > > 4. On the agreed dates, activate peering > > 5. When experiment is over, shut down peering > > Did I miss anything? > > > Cheers, > Lorenzo > > -- > Lorenzo Colitti lorenzo at ripe.net > Network Engineer +31-20-5354471 > RIPE NCC www.ripe.net > -- Arife Vural SED, RIPE NCC From lorenzo at ripe.net Mon Mar 13 16:19:05 2006 From: lorenzo at ripe.net (Lorenzo Colitti) Date: Mon, 13 Mar 2006 16:19:05 +0100 Subject: [ris-int] Re: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <4410716B.9070905@comp.polyu.edu.hk> References: <20060309140336.GK20624@ripe.net> <441040CF.9050800@ripe.net> <4410716B.9070905@comp.polyu.edu.hk> Message-ID: <44158D69.8070008@ripe.net> Samantha Lo wrote: > Dear Lorenzo, > > Thank you for your kind consideration. > We are looking forward to your favorable reply. Hi Samantha, we have looked into this and we have determined that we do not have the resources to do what you have requested. However, we would like to suggest an alternative. We can set up an IBGP peering session between a BGP speaker of your choice and one of our RRCs (RRC07). You would thus be inside AS12654. You could then announce the two prefixes 84.205.73.0/24 and 84.205.89.0/24, which are RIS beacons, with AS-paths of the form "12654 i". These paths will be announced to the transit peers of RRC07. Note that if you use your own AS in the AS-path, it might get filtered out since our peers might filter on origin AS. However, you could prepend AS 12654 multiple times. If you do not have software to generate IBGP announcements, you can use the "announcer" tool [1] to do this. I wrote this tool and have used it successfully for other research work [2]. Combined with a cron script, it should be sufficient for your needs. (If it's not, let me know what it's missing!). If you think this would be useful to you, please provide us with a few lines describing your experiment and what kind of paths you will announce so that we can inform our upstream peers. If our peers agree, we can then discuss the dates on which we will set up the peering and on which you will perform your experiments. Regards, Lorenzo [1] http://www.dia.uniroma3.it/~compunet/bgp-probing/announcer/ [2] Colitti et al., "Investigating prefix propagation through active BGP probing", to appear in Proceedings of IEEE ISCC 2006. -- Lorenzo Colitti lorenzo at ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net From wilhelm at ripe.net Mon Mar 13 16:32:37 2006 From: wilhelm at ripe.net (Rene Wilhelm) Date: Mon, 13 Mar 2006 16:32:37 +0100 Subject: [ris-int] quagga & 4-byte ASN support Message-ID: <20060313153237.AE46D2F583@herring.ripe.net> Searching for the status of 4-byte ASN support in quagga I couldn't see a word on this in the official mailing lists at http://lists.quagga.net/ But after a little googling I found Paul Jamka's weblog http://blogs.sun.com/roller/page/paulj?catname=%2FNetworking which (in the March 10 entry) says: The short answer is that Quagga is part-way towards 4-byte ASN support [...] That leaves the following (generally) as still to be implemented: 1. The 4-byte-supported BGP capability 2. Extending the unit tests with equivalent 4-byte forms and verifying the AS_PATH parser and transformational functions. 3. Using the appropriate encoding for AS_PATH according to the remote peer 4. Adding support for the 2<->4 byte transition mechanisms (unit tests implied) 1, 2 and 3 should be quite easy, 2 weeks about, including testing, and would get bgpd to the stage which the draft RFC calls a "NEW" speaker and interoperate fully with other "NEW" speakers. It would also be able to speak to "OLD" peers, provided no 4-byte wide ASNs are involved. Support for these items I hope to see in Quagga before the end of the year. That leaves 4, which isn't as easy, further I am not very optimistic on its chances of working. I suspect the internet would be in trouble if we end up relying on the 4-byte transition mechanism to work. I really hope all deployed speakers of significance end up being upgraded to "NEW" (ie corresponding to at least 1,2 and 3 above) well before the first 4-byte ASNs are issued, so that we never have to find out how well the transition mechanisms might work.. His hopes may prove faint, especially when (according to the proposed policy) RIRs start allocating/assigning 4-byte ASNs by default come 1/1/2009; it'll be interesting times. However, it is clear the issue has the quagga author(s) attention; there's no need for RIPE NCC to step in. -- Rene P.S. Interesting side fact: the last real Quagga died in Artis, Amsterdam's zoo, some 123 years ago. :) From arife at ripe.net Mon Mar 13 17:01:12 2006 From: arife at ripe.net (Arife Vural) Date: Mon, 13 Mar 2006 17:01:12 +0100 Subject: [ris-int] quagga & 4-byte ASN support In-Reply-To: <20060313153237.AE46D2F583@herring.ripe.net> References: <20060313153237.AE46D2F583@herring.ripe.net> Message-ID: <20060313160111.GM18361@ripe.net> Hi Rene, Lately, I exchanged some e-mail with Paul Jakma, as you said they try to support 4byte ASn sometime this year ... Will forward his e-mail seperately. Arife On Mon, Mar 13, 2006 at 04:32:37PM +0100, Rene Wilhelm wrote: > Searching for the status of 4-byte ASN support in quagga > I couldn't see a word on this in the official mailing lists > at http://lists.quagga.net/ > > But after a little googling I found Paul Jamka's weblog > http://blogs.sun.com/roller/page/paulj?catname=%2FNetworking > which (in the March 10 entry) says: > > The short answer is that Quagga is part-way towards 4-byte ASN support > > [...] That leaves the following (generally) as still to be implemented: > > 1. The 4-byte-supported BGP capability > 2. Extending the unit tests with equivalent 4-byte forms and verifying > the AS_PATH parser and transformational functions. > 3. Using the appropriate encoding for AS_PATH according to the remote peer > 4. Adding support for the 2<->4 byte transition mechanisms (unit tests > implied) > > 1, 2 and 3 should be quite easy, 2 weeks about, including testing, and > would get bgpd to the stage which the draft RFC calls a "NEW" speaker and > interoperate fully with other "NEW" speakers. It would also be able to > speak to "OLD" peers, provided no 4-byte wide ASNs are involved. Support > for these items I hope to see in Quagga before the end of the year. > > That leaves 4, which isn't as easy, further I am not very optimistic on > its chances of working. I suspect the internet would be in trouble if we > end up relying on the 4-byte transition mechanism to work. I really hope > all deployed speakers of significance end up being upgraded to "NEW" > (ie corresponding to at least 1,2 and 3 above) well before the first > 4-byte ASNs are issued, so that we never have to find out how well > the transition mechanisms might work.. > > > His hopes may prove faint, especially when (according to the proposed policy) > RIRs start allocating/assigning 4-byte ASNs by default come 1/1/2009; > it'll be interesting times. > > However, it is clear the issue has the quagga author(s) attention; > there's no need for RIPE NCC to step in. > > -- Rene > > P.S. Interesting side fact: the last real Quagga died in Artis, > Amsterdam's zoo, some 123 years ago. :) > -- Arife Vural SED, RIPE NCC From arife at ripe.net Mon Mar 13 17:02:17 2006 From: arife at ripe.net (Arife Vural) Date: Mon, 13 Mar 2006 17:02:17 +0100 Subject: [ris-int] [paul@clubi.ie: Re: RIPE RIS / Quagga] Message-ID: <20060313160217.GN18361@ripe.net> ----- Forwarded message from Paul Jakma ----- From: Paul Jakma To: Arife Vural Subject: Re: RIPE RIS / Quagga Date: Wed, 8 Mar 2006 13:53:18 +0000 (GMT) Mail-Followup-To: paul at hibernia.jakma.org On Wed, 8 Mar 2006, Arife Vural wrote: >We run Quagga 0.96.5. I think we have that version more than a >year. Wow. :) I think it has an IPv6 attribute related DoS btw. At least, the SIXXS ghosthunter had to upgrade to 0.98 because someone was injecting something into global IPv6 that took down old 0.96ish bgpd's. >Until now, we did not have any big performance problem related with >Quagga. We have to run mySQL and DBinsert on route collectors in >addition to Quagga to insert data into DB. We had a memory leak in >DBinsert process, it was eating up the all memory and was killing >the deamons including bgpd. We kind of get round that problem. Now, >bgpd seems to be quite OK. :) >We have problem only on RRC03 (AMS-IX). It's the biggest route >collector. It has peering session about 130. Only thing, I observe >is the bgpd response time. It is bit slow. It takes a while (less >than a minute) to configure a session. Interesting. >But be honest, I do not know how bgp traffic is effected with this >slowness. We do not have tool to check the consistency of BGP >updates. Until now, I have not heard any comment from our users >about complaining the consistency of the data. Consistency is probably good. What you may notice is that sometimes sessions drop for no apparent reason (typically co-inciding with the telnet interface being unresponsive). This we have, I think, fixed. >We have looking glass here, please have a look at and decide which >RRC will be a good example for you, than I will try to provide you >the performance graph of that RRC. The ones I'm interested in are: RRC01 (Linx) RRC03 (AMS-IX) I'm particularly interested in the following outputs: >From bgpd's telnet interface: - 'show memory bgp' - 'show memory lib' - 'show ip bgp sum' (at the time above are taken) >From your operating system (in whatever way): - the total memory usage of bgpd That would be *very* informative. We intend to try bgpd on a diet - there's some low-hanging fruit and I think we can easily reduce usage by 10% or so. Output from RRC01 and RRC03 would be very useful in determining where else "dieting" would have biggest effect on bgpd (both RRC's if possible -> so we can see how objects scale with number of sessions / prefixes / paths). That would be *great* if you could provide that. :) >I just checked the performance graphs some of them are missing, but >I'm sure we can find one that will be useful for you. We use Orca >tool to get performance graphs I hope it would be useful for you. Very neat. >This is the "show thread cpu" from RRC03. > >rrc03> show thread cpu >Runtime(ms) Invoked Avg uSecs Max uSecs Type Thread >2165490.000 7184 301432 36150000 T bgp_dump_interval_func >1537621.376 35511 43299 4710000 T bgp_scan >3676941.376 60175283 61 4570000 E bgp_event > 229430.000 384 597473 3850000 T bgp_holdtime_timer >1900803.568 142918849 13 36150000 RWTEX TOTAL Interesting, bgp_dump_interval_func() took the longest. We should probably run it as a child process, if possible. >If you like to see the output of the other RRCs, please let me know. >BTW, we do not run zebra daemon. I would have thought so. Avoids bulk of the performance problems too. >About using the new version, I think we are bit conservative. >Until, we have problem or a security issue, we are happy to using >old version. Ok. >BTW 2, I have a question for you. Is there any plan about implementing >32bit AS number in Quagga? Yes, the internal AS_PATH parsing code was partially rewritten late last year to make the internal representation of AS_PATHs indepedent of the wire format, specifically in order to make it ready (internally) for 4-byte ASNs. Ie the internal format is now just a change of a typedef away from 4-byte ASNs. (We also have, with that rewrite, an extensive set of AS_PATH code exercising unit tests to verify nothing breaks). Didn't yet get as far as adding support for the 4-byte capability or its required attributes, or the transition mechanism of NEW_AS_PATH (and unit tests to verify them). Later this year hopefully. regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A Fortune: You will be dead within a year. ----- End forwarded message ----- -- Arife Vural SED, RIPE NCC From wilhelm at ripe.net Mon Mar 13 17:13:37 2006 From: wilhelm at ripe.net (Rene Wilhelm) Date: Mon, 13 Mar 2006 17:13:37 +0100 Subject: [ris-int] quagga & 4-byte ASN support In-Reply-To: Message from arife@ripe.net (Arife Vural) of "Mon, 13 Mar 2006 17:01:12 +0100." <20060313160111.GM18361@ripe.net> Message-ID: <20060313161337.638992F583@herring.ripe.net> Hi Arife, > Lately, I exchanged some e-mail with Paul Jakma, as you said they > try to support 4byte ASn sometime this year ... > > Will forward his e-mail seperately. Thanks for forwarding. Could well have been your mail which triggered Paul into writing his blog entry: "I've been asked a couple of times recently about support for the upcoming BGP 4 byte ASN RFC ..." :-) Cheers, -- Rene From wilhelm at ripe.net Tue Mar 14 02:21:51 2006 From: wilhelm at ripe.net (Rene Wilhelm) Date: Tue, 14 Mar 2006 02:21:51 +0100 (CET) Subject: [ris-int] Introduction of 4-byte ASN: RIS & TTM view Message-ID: Leo, Attached is the XLS sheet with, as far as I can see, the list of things that needs to be done in RIS and TTM to be able to handle 4-byte long AS numbers in the routing system. -- Rene -------------- next part -------------- A non-text attachment was scrubbed... Name: 32bitASN.xls Type: application/octet-stream Size: 13824 bytes Desc: URL: From isnmvajka at kobej.zzn.com Tue Mar 14 06:56:13 2006 From: isnmvajka at kobej.zzn.com (isnmvajka at kobej.zzn.com) Date: Tue, 14 Mar 2006 06:56:13 +0100 (CET) Subject: [ris-int] =?iso-2022-jp?B?g1SDQ4NnlcqCyYNmgVuDXoLGjVWXqpZAgvCLTI3a?= Message-ID: 20060314125708.72415mail@mail.koqspoo28759-superderisystem_server65-getwoman114.cc ???????????????????????????????????????????????????????????????? ?@?@???@Deai?????????m?????@?? ?@?@?@?@?@?@?@?@?@?V???????K?v????????GET???????I?I ?@?@?@?@?@?@?@?@?@?@?@?@http://www.ai-love-you.net/tv/ ???????????????????????????????????????????????????????????????? ==INDEX======================================================== ?y_1_?z???????????????A???????o?????T?C?g????50?T?C?g???????? ?y_2_?z?????????W?@?w?{?C???o?????????x ?y_3_?z???????????????????@?X???C???^?r???[ ?y_4_?z?l?C?}???????@?????????????E?E?E?B ?y_5_?z?h?????????????E?E?E?s?????]?I?I ?y_6_?z?V???o???l???o?????n?@?@http://www.ai-love-you.net/tv/ =============================================================== ?@???????s???E?n?k?E?????w?E?w???E?????E?l???E?????F?????? ?e?W?????????????????????M???D???????????????T???o???????I?I 24?????????????????D???????????f?n?I?I ???????l?b?g?i???p?n?L?????y?[???????{?\?? ?@http://www.ai-love-you.net/tv/ ---------------------------------------------------------------------- ?o?^???????????]???????A???????????????L????????????????????m(_ _)m ???????@Unsubscribe mail service?@?????? (http://www.ai-love-you.net/tv/release.php) ---------------------------------------------------------------------- From cssmlo at comp.polyu.edu.hk Wed Mar 15 07:04:02 2006 From: cssmlo at comp.polyu.edu.hk (Samantha Lo) Date: Wed, 15 Mar 2006 14:04:02 +0800 Subject: [ris-int] Re: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <44158D69.8070008@ripe.net> References: <20060309140336.GK20624@ripe.net> <441040CF.9050800@ripe.net> <4410716B.9070905@comp.polyu.edu.hk> <44158D69.8070008@ripe.net> Message-ID: <4417AE52.5000800@comp.polyu.edu.hk> Hi Lorenzo, Thank you so much for your prompt reply and the suggested setup. I think the setup should be adequate for our experiments, except that for a given prefix we generally need to advertise the prepended routes to some (e.g., 1) upstream ASs and unprepended routes to others. Can the setup that you suggested enable us to do that (through an access list, or different peer sessions, or community but which is not supported by the announcer you provided, or peer to more than one RRC)? In the meantime, we will set up a BGP speaker here with the announcer. But if the announcer is not adequate for announcing prefixes with different prepending lengths to different upstream ASs, we may need to use some software routers. We are planning to submit a paper to the IMC conf, and the deadline is late May. If you are interested, you are welcome to join our work. Best regards, Samantha Lorenzo Colitti said the following on 3/13/2006 11:19 PM: > Samantha Lo wrote: >> Dear Lorenzo, >> >> Thank you for your kind consideration. >> We are looking forward to your favorable reply. > > Hi Samantha, > > we have looked into this and we have determined that we do not have > the resources to do what you have requested. However, we would like to > suggest an alternative. > > We can set up an IBGP peering session between a BGP speaker of your > choice and one of our RRCs (RRC07). You would thus be inside AS12654. > You could then announce the two prefixes 84.205.73.0/24 and > 84.205.89.0/24, which are RIS beacons, with AS-paths of the form > "12654 i". These paths will be announced to > the transit peers of RRC07. > > Note that if you use your own AS in the AS-path, it might get filtered > out since our peers might filter on origin AS. However, you could > prepend AS 12654 multiple times. > > If you do not have software to generate IBGP announcements, you can > use the "announcer" tool [1] to do this. I wrote this tool and have > used it successfully for other research work [2]. Combined with a cron > script, it should be sufficient for your needs. (If it's not, let me > know what it's missing!). > > If you think this would be useful to you, please provide us with a few > lines describing your experiment and what kind of paths you will > announce so that we can inform our upstream peers. If our peers agree, > we can then discuss the dates on which we will set up the peering and > on which you will perform your experiments. > > > Regards, > Lorenzo > > [1] http://www.dia.uniroma3.it/~compunet/bgp-probing/announcer/ > [2] Colitti et al., "Investigating prefix propagation through active > BGP probing", to appear in Proceedings of IEEE ISCC 2006. > From postcards at postcards1001.com Wed Mar 15 21:26:13 2006 From: postcards at postcards1001.com (postcards1001) Date: Wed, 15 Mar 2006 21:26:13 +0100 (CET) Subject: [ris-int] You've received a greeting from a family member! Message-ID: <20060315202613.428E716B59D2@mail.studioubachswisbrun.nl> An HTML attachment was scrubbed... URL: From postcards at postcards1001.com Wed Mar 15 23:45:08 2006 From: postcards at postcards1001.com (postcards1001) Date: Wed, 15 Mar 2006 23:45:08 +0100 (CET) Subject: [ris-int] You've received a greeting from a family member! Message-ID: <20060315224508.3DF041701F34@mail.studioubachswisbrun.nl> An HTML attachment was scrubbed... URL: From henk at ripe.net Thu Mar 16 07:59:54 2006 From: henk at ripe.net (Henk Uijterwaal) Date: Thu, 16 Mar 2006 07:59:54 +0100 Subject: [ris-int] Re: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <4417AE52.5000800@comp.polyu.edu.hk> References: <20060309140336.GK20624@ripe.net> <441040CF.9050800@ripe.net> <4410716B.9070905@comp.polyu.edu.hk> <44158D69.8070008@ripe.net> <4417AE52.5000800@comp.polyu.edu.hk> Message-ID: <7.0.1.0.2.20060316075543.0338ece0@ripe.net> (Internal reply) >We are planning to submit a paper to the IMC conf, and the deadline is >late May. If you are interested, you are welcome to join our work. Sounds like a good idea, but I like to see the paper before it is submitted. 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 ------------------------------------------------------------------------------ 1160438400. Watch this space... From cssmlo at comp.polyu.edu.hk Fri Mar 17 07:30:21 2006 From: cssmlo at comp.polyu.edu.hk (Samantha Lo) Date: Fri, 17 Mar 2006 14:30:21 +0800 Subject: [ris-int] Re: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <44158D69.8070008@ripe.net> References: <20060309140336.GK20624@ripe.net> <441040CF.9050800@ripe.net> <4410716B.9070905@comp.polyu.edu.hk> <44158D69.8070008@ripe.net> Message-ID: <441A577D.6010409@comp.polyu.edu.hk> Hi Lorenzo, Thank you so much for your prompt reply and the suggested setup. I think the setup should be adequate for our experiments, except that for a given prefix we generally need to advertise the prepended routes to some (e.g., 1) upstream ASs and unprepended routes to others. Can the setup that you suggested enable us to do that (through an access list, or different peer sessions, or community but which is not supported by the announcer you provided, or peer to more than one RRC)? In the meantime, we will set up a BGP speaker here with the announcer. But if the announcer is not adequate for announcing prefixes with different prepending lengths to different upstream ASs, we may need to use some software routers. We are planning to submit a paper to the IMC conf, and the deadline is late May. If you are interested, you are welcome to join our work. Best regards, Samantha http://www.comp.polyu.edu.hk/~cssmlo/ cssmlo at comp.polyu.edu.hk Phone: +852-27764901 Fax: +852-27740842 Lorenzo Colitti said the following on 3/13/2006 11:19 PM: > Samantha Lo wrote: >> Dear Lorenzo, >> >> Thank you for your kind consideration. >> We are looking forward to your favorable reply. > > Hi Samantha, > > we have looked into this and we have determined that we do not have > the resources to do what you have requested. However, we would like to > suggest an alternative. > > We can set up an IBGP peering session between a BGP speaker of your > choice and one of our RRCs (RRC07). You would thus be inside AS12654. > You could then announce the two prefixes 84.205.73.0/24 and > 84.205.89.0/24, which are RIS beacons, with AS-paths of the form > "12654 i". These paths will be announced to > the transit peers of RRC07. > > Note that if you use your own AS in the AS-path, it might get filtered > out since our peers might filter on origin AS. However, you could > prepend AS 12654 multiple times. > > If you do not have software to generate IBGP announcements, you can > use the "announcer" tool [1] to do this. I wrote this tool and have > used it successfully for other research work [2]. Combined with a cron > script, it should be sufficient for your needs. (If it's not, let me > know what it's missing!). > > If you think this would be useful to you, please provide us with a few > lines describing your experiment and what kind of paths you will > announce so that we can inform our upstream peers. If our peers agree, > we can then discuss the dates on which we will set up the peering and > on which you will perform your experiments. > > > Regards, > Lorenzo > > [1] http://www.dia.uniroma3.it/~compunet/bgp-probing/announcer/ > [2] Colitti et al., "Investigating prefix propagation through active > BGP probing", to appear in Proceedings of IEEE ISCC 2006. > From lorenzo at ripe.net Fri Mar 17 12:35:28 2006 From: lorenzo at ripe.net (Lorenzo Colitti) Date: Fri, 17 Mar 2006 12:35:28 +0100 Subject: [ris-int] Re: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <441A577D.6010409@comp.polyu.edu.hk> References: <20060309140336.GK20624@ripe.net> <441040CF.9050800@ripe.net> <4410716B.9070905@comp.polyu.edu.hk> <44158D69.8070008@ripe.net> <441A577D.6010409@comp.polyu.edu.hk> Message-ID: <441A9F00.1030402@ripe.net> Samantha Lo wrote: > Thank you so much for your prompt reply and the suggested setup. I think > the setup should be adequate for our experiments, except that for a > given prefix we generally need to advertise the prepended routes to some > (e.g., 1) upstream ASs and unprepended routes to others. Can the setup > that you suggested enable us to do that (through an access list, or > different peer sessions, or community but which is not supported by the > announcer you provided, or peer to more than one RRC)? Unfortunately, it seems to me that this cannot be done as I suggested. The announcer is flexible enough to announce different AS-paths for different peers. However, since these routes will be announced to the same RRC, it doesn't matter what you announce, because the RRC will perform route selection and only announce one AS-path to all its upstreams. I have been trying to think of a solution that does not require modifying the RRC's configuration in a non-trivial way, but the only thing that comes to mind is that you do the different prepending with two different prefixes, which is not particularly realistic. We could of course set up multiple IBGP peerings between you and multiple RRCs, but the problem with that are that the RRCs are in different locations and have different transit providers. I don't know if this is adequate for your experiments. What would you suggest? > In the meantime, we will set up a BGP speaker here with the announcer. > But if the announcer is not adequate for announcing prefixes with > different prepending lengths to different upstream ASs, we may need to > use some software routers. Unfortunately, the announcer is not the problem here because it doesn't peer directly with our upstreams but would go through the RRC, which performs route selection. What did you have in mind? > We are planning to submit a paper to the IMC conf, and the deadline is > late May. If you are interested, you are welcome to join our work. I would definitely be interested to know what you have in mind. I have read the two-page abstract, but I don't really understand, for example, how this is different from the work you presented at NOMS 2004? (I was in the same session, presenting IPv6-in-IPv4 tunnel discovery...) Regards, Lorenzo -- Lorenzo Colitti lorenzo at ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net From cssmlo at comp.polyu.edu.hk Sat Mar 18 11:23:48 2006 From: cssmlo at comp.polyu.edu.hk (Samantha Lo) Date: Sat, 18 Mar 2006 18:23:48 +0800 Subject: [ris-int] Re: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <441A9F00.1030402@ripe.net> References: <20060309140336.GK20624@ripe.net> <441040CF.9050800@ripe.net> <4410716B.9070905@comp.polyu.edu.hk> <44158D69.8070008@ripe.net> <441A577D.6010409@comp.polyu.edu.hk> <441A9F00.1030402@ripe.net> Message-ID: <441BDFB4.1030703@comp.polyu.edu.hk> Hi Lorenzo, Lorenzo Colitti said the following on 3/17/2006 7:35 PM: > Samantha Lo wrote: >> Thank you so much for your prompt reply and the suggested setup. I think >> the setup should be adequate for our experiments, except that for a >> given prefix we generally need to advertise the prepended routes to some >> (e.g., 1) upstream ASs and unprepended routes to others. Can the setup >> that you suggested enable us to do that (through an access list, or >> different peer sessions, or community but which is not supported by the >> announcer you provided, or peer to more than one RRC)? > > Unfortunately, it seems to me that this cannot be done as I suggested. > The announcer is flexible enough to announce different AS-paths for > different peers. However, since these routes will be announced to the > same RRC, it doesn't matter what you announce, because the RRC will > perform route selection and only announce one AS-path to all its > upstreams. > > I have been trying to think of a solution that does not require > modifying the RRC's configuration in a non-trivial way, but the only > thing that comes to mind is that you do the different prepending with > two different prefixes, which is not particularly realistic. > > We could of course set up multiple IBGP peerings between you and > multiple RRCs, but the problem with that are that the RRCs are in > different locations and have different transit providers. I don't know > if this is adequate for your experiments. > > What would you suggest? > I suggest that we can have multiple RRCs with different upstream providers (better no overlaps). I think the location would not be a problem in our measurement. We can further investigate the response of the upstreams to the prepending in different situations, e.g. locations (but I don't think location would have any effect to the response. Instead, the policies of the upstreams would be affected. That's why I would like to know the policies of your upstreams.) >> In the meantime, we will set up a BGP speaker here with the announcer. >> But if the announcer is not adequate for announcing prefixes with >> different prepending lengths to different upstream ASs, we may need to >> use some software routers. > > Unfortunately, the announcer is not the problem here because it > doesn't peer directly with our upstreams but would go through the RRC, > which performs route selection. What did you have in mind? So, your announcer would be perfectly fit in our measurement. But I am still not very sure how to set up an iBGP section from my university network to the RRCs.Would you give me more details? > >> We are planning to submit a paper to the IMC conf, and the deadline is >> late May. If you are interested, you are welcome to join our work. > > I would definitely be interested to know what you have in mind. I have > read the two-page abstract, but I don't really understand, for > example, how this is different from the work you presented at NOMS > 2004? (I was in the same session, presenting IPv6-in-IPv4 tunnel > discovery...) > The paper presented in NOMS 2004 is my supervisor's work. It is another approach compared with this one but the objectives are quite similar. The one presented in NOMS 2004 is in an "Black box" approach. It only gets back the ping responses from the top senders (from the netflow data) but doesn't check out the AS Paths after performed prepending. As a result, we can only observe the change of the inbound traffic (ping responses changed from one link to another) but cannot understand why the traffic has been changed. My approach is "open the black box" to check the AS paths from the looking glasses and route servers. So, after the prepending, we get the AS Paths and check that whether the best paths have been changed. In fact, we have performed this in my 2-page abstract and observed some phenomenon, e.g. prepending invariant sub-paths, and how the best paths are propagated. We want to further investigate them in other ASes to see if the responses are similar such that we may predict the result of AS path prepending. i.e. How long the prepending length should be in order to shift an amount of traffic? Also, if it is possible, we can check out the performance of the the new path after performed prepending, e.g. available BW. I have already prepared a script (written by perl) to get the AS paths from about 100 looking glasses automatically. I am looking into the updates in routeviews of the archives that we performed the measurement and find out some patterns after I performed the prepending. But because we only used one prefix in the previous measurement, we cannot conclude that some of the events may be caused by prepending only. > > Regards, > Lorenzo > What do you think? I may not explain very clearly here but I can further provide you details. We can further discuss it. I am looking forward to your favorable reply. Best regards, Samantha http://www.comp.polyu.edu.hk/~cssmlo/ cssmlo at comp.polyu.edu.hk Phone: +852-27764901 Fax: +852-27740842 From lorenzo at ripe.net Wed Mar 22 11:01:56 2006 From: lorenzo at ripe.net (Lorenzo Colitti) Date: Wed, 22 Mar 2006 11:01:56 +0100 Subject: [ris-int] Re: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <441BDFB4.1030703@comp.polyu.edu.hk> References: <20060309140336.GK20624@ripe.net> <441040CF.9050800@ripe.net> <4410716B.9070905@comp.polyu.edu.hk> <44158D69.8070008@ripe.net> <441A577D.6010409@comp.polyu.edu.hk> <441A9F00.1030402@ripe.net> <441BDFB4.1030703@comp.polyu.edu.hk> Message-ID: <44212094.2080008@ripe.net> Samantha Lo wrote: >> What would you suggest? >> > I suggest that we can have multiple RRCs with different upstream > providers (better no overlaps). This is possible: we can set up multiple IBGP peerings to multiple RRCs and have those RRCs provide transit. For determining which RRCs are best to use in order not to have overlap between upstreams, perhaps you could use the RIS looking glass to see who provides transit for the beacon prefix of each RRC. That gives you an easy way to check who provides transit for each RRC and thus who would provide transit for your prefix if you were to announce it from that RRC. A list of the beacon prefixes announced by each RRC is here: http://www.ripe.net/projects/ris/docs/beaconlist.html Here you can also see where each RRC is located. > We can further investigate the response of the upstreams to the > prepending in different situations, e.g. locations (but I don't think > location would have any effect to the response. Instead, the policies > of the upstreams would be affected. That's why I would like to know > the policies of your upstreams.) As far as I know, when we request transit for a beacon prefix, the agreement is "treat this prefix exactly as though we were a stub customer of yours". The routing policies of our upstreams are another matter, but perhaps once you know better which RRCs and thus which upstreams you will be using you can look up this information in the RIPE routing database (Or perhaps we can try to confirm this with them directly. Note, however, that this is likely proprietary information that cannot be published.) > So, your announcer would be perfectly fit in our measurement. But I am > still not very sure how to set up an iBGP section from my university > network to the RRCs.Would you give me more details? Once we know more about the setup you want to use, e.g. which RRCs you want to use, which prefixes you want to announce and where, I can configure IBGP sessions between an IP address you give me and the RRCs and give you the info you need to set up the peering on your side. Depending on the RRC, we might need to do other things like open the firewall. Cheers, Lorenzo -- Lorenzo Colitti lorenzo at ripe.net Network Engineer +31-20-5354471 RIPE NCC www.ripe.net From cssmlo at comp.polyu.edu.hk Thu Mar 23 07:01:39 2006 From: cssmlo at comp.polyu.edu.hk (Samantha Lo) Date: Thu, 23 Mar 2006 14:01:39 +0800 Subject: [ris-int] Re: NCC#2006021124 [RIS Lease-A-Beacon Request] In-Reply-To: <44212094.2080008@ripe.net> References: <20060309140336.GK20624@ripe.net> <441040CF.9050800@ripe.net> <4410716B.9070905@comp.polyu.edu.hk> <44158D69.8070008@ripe.net> <441A577D.6010409@comp.polyu.edu.hk> <441A9F00.1030402@ripe.net> <441BDFB4.1030703@comp.polyu.edu.hk> <44212094.2080008@ripe.net> Message-ID: <442239C3.3040405@comp.polyu.edu.hk> Lorenzo Colitti said the following on 3/22/2006 6:01 PM: > Samantha Lo wrote: >>> What would you suggest? >>> >> I suggest that we can have multiple RRCs with different upstream >> providers (better no overlaps). > > This is possible: we can set up multiple IBGP peerings to multiple > RRCs and have those RRCs provide transit. > > For determining which RRCs are best to use in order not to have > overlap between upstreams, perhaps you could use the RIS looking glass > to see who provides transit for the beacon prefix of each RRC. That > gives you an easy way to check who provides transit for each RRC and > thus who would provide transit for your prefix if you were to announce > it from that RRC. > > A list of the beacon prefixes announced by each RRC is here: > > http://www.ripe.net/projects/ris/docs/beaconlist.html > > Here you can also see where each RRC is located. > I am looking into them now. Let me get back to you in these two days. I think I need to look into those providers' policies in RIPE and determine which RRCs we would use. But I find that many of them have overlaps. I >> We can further investigate the response of the upstreams to the >> prepending in different situations, e.g. locations (but I don't think >> location would have any effect to the response. Instead, the policies >> of the upstreams would be affected. That's why I would like to know >> the policies of your upstreams.) > > As far as I know, when we request transit for a beacon prefix, the > agreement is "treat this prefix exactly as though we were a stub > customer of yours". The routing policies of our upstreams are another > matter, but perhaps once you know better which RRCs and thus which > upstreams you will be using you can look up this information in the > RIPE routing database (Or perhaps we can try to confirm this with them > directly. Note, however, that this is likely proprietary information > that cannot be published.) I understand that. Our previous measurement which submitted to IMC has this problem also. We cannot disclose the information of the AS. > >> So, your announcer would be perfectly fit in our measurement. But I am >> still not very sure how to set up an iBGP section from my university >> network to the RRCs.Would you give me more details? > > Once we know more about the setup you want to use, e.g. which RRCs you > want to use, which prefixes you want to announce and where, I can > configure IBGP sessions between an IP address you give me and the RRCs > and give you the info you need to set up the peering on your side. > Depending on the RRC, we might need to do other things like open the > firewall. I see. Thank you very much! > > > Cheers, > Lorenzo > Best regards, Samantha Lo http://www.comp.polyu.edu.hk/~cssmlo/ cssmlo at comp.polyu.edu.hk Phone: +852-27764901 Fax: +852-27740842 From comfor at dwyergroup.com Sat Mar 25 12:11:01 2006 From: comfor at dwyergroup.com (Comfort Weyer) Date: Sat, 25 Mar 2006 06:11:01 -0500 Subject: [ris-int] Re: maLoy50 news Message-ID: <000001c64ffc$cd28e4c0$def1a8c0@bib16> Hi Do you want to OVER P A Y for your MEDs ? Nothing like you need it, S A V E yourself 50 % with http://www.ellorthecin.com \/ \/ C A I l L A A l G L U R I M A S $ $ $ 8 6 6 5 9 7 , , , 4 9 5 5 5 0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From henk at ripe.net Fri Mar 31 14:46:48 2006 From: henk at ripe.net (Henk Uijterwaal) Date: Fri, 31 Mar 2006 14:46:48 +0200 Subject: [ris-int] Fwd: RIS things, was Re: [np] Conf report: Peering Forum Message-ID: <7.0.1.0.2.20060331144644.034841d8@ripe.net> >Date: Fri, 31 Mar 2006 14:38:49 +0200 >To: Arife Vural >From: Henk Uijterwaal >Subject: RIS things, was Re: [np] Conf report: Peering Forum >Cc: ris > >Hi Arife, > >(Distribution list reduced) > >Thanks, interesting. In case you ever want to do a ris-overview >talk, I do have a presentation on the shelf. (And I also have >generic NCC services talk). Something else: > >2 RIS related things I heard at the IETF: > > 1. Geoff Huston complained that it was hard to download the full > data sets. Simon Leinen suggested in the IEPG to put the data > on bittorrent and even offered 2 machines with diskspace as > servers. I promised to take this up here. > > 2. Geoff showed all kinds of activity plots. Some of them are related > to the hotspots and BGP update plots that we have. I tried to find > them in the meeting but failed. Slightly related: a few weeks ago, > Rene reported that some of the standard plots had not been updated > since December. That means that nobody looked at them for two > months. Which means that they are probably not too useful and we > should consider using the CPU cycles for something else. > > Perhaps we should review the standard set of RIS plots that we > produce, remove what is never used, add new plots and make it a > bit easier to find. > >And at APNIC: > > 3. Milton (RRC15 host) asked about installing 7 or so RRC's in the LACNIC > region. His idea was to have RRC's at all IX's there, so people could > really debug problems in the LACNIC area. > > This is probably a good idea FOR THEM, I just wonder if we should be > operating this. If it is LACNIC specific, then it might be better to > tell then HOW the RIS works and have them copy the system. They > can then operate it themselves. > > I also promised to bring this up internally. > >Perhaps we can meet and discuss all this sometime soon? > >Henk > > > > >At 21:16 27/03/2006, Arife Vural wrote: > >>Conference report: >> >>Conference: Peering Forum >>Date: 18.03.2006 - 23.03.2006 >>Venue: Miami, US >>URL: http://www.peeringforum.com >>Attendee(s): Arife Vural >>Department(s): SED >> >>* Scope of conference: >> >>Everything that's related with Peering >> >> >>* Reason for attendance: >> >>Related with my job >> >> >>* Summary (main aspects & outcome of the conference, personal evaluation >> thereof, impressions, interesting floor talks etc.): >> >>o Met a lot of people peering people. >> >>o Had chat with De-CIX guys. They offered us to have a RIS presentation in >>one of their technical meetings. One is in April and the other one is in >>October. Bernhard Kr??nung is the contact person to discuss the detail more >>He wil be attending RIPE52. >> >>Bernhard also mentioned about OpneBGPD software. They are planing to use on >>their route server. He said it's more stable than Quagga. It does not crash >>so often. It has a mode to configure as route server. That mode allows BGP >>speaker to announce all routes it gets from the peers rather than only the >>best ones. >> >>It might worth to spend some cycles on it to find out pros & cons. >> >>o I got some free transit donation for >>K-anycast server. Thanks Josh Snowhorn, >>Terramark for his help. Some of them already contacted with OPS. With some I >>will contact during the week. Some of those >>guys are also willing to peer with >>RIS. >> >>TeleGlobe, Delhi is offered free transit. I >>think it would be nice to have with >>eBGP on RRC00. We do not have any peers in that part of the world. >> >>o prolexic.com >> >>Those guys are protecting companies from DDos >>attacks. They are doing quite a >>good job chasing the hackers. They work with >>FBI and other organization to track >>them down. It's a small company. When they find >>a site is under DDos attack, by >>using BGP and DNS, they directed to the routes >>on their servers and work on to stop >>the attack, while the original site is up and running. They have quite a few >>customers. >> >>o QoS >> >>There was a panel about QoS effort at IX >>points. Most of IXs do not do anything >>other than watching their bandwith usage statistics. Henk Steenman mentioned >>about TTM box they have at AMS-IX to measure >>the gitter. He said those graphs are >>publicly available. Data&Switch and TeleGlobe >>might consider go such a solution. >> >>I have to contact with them about RIS peering, >>during that time I will send link >>about TTM. >> >>o Next PeeringForum >> >>If there will be Peering Forum next year, it >>would be worth to put a presentation >>about what RIPE NCC does and mention the projects like RIS, TTM and Routing >>Registry Courses and roughly what we do at the RIPE NCC. >> >>Some people have no idea what we do. Some knows >>quite well and ask question like >>what RIPE NCC does with all the money they get. >>I think such 30 mins presentation >>would help to clear those questions. >> >>o ENUM >> >>It looks quite trendy when IXs mention they do >>support ENUM. I do not know exactly >>what kind of works involve from IXs, but it would be worth to coordinate the >>ENUM work (which Katie is doing) with those guys. >> >>o IRR Power Toolset >> >>This is a similar tool like IRR toolset. >>Richard Steenbergen gave a presentation >>about it. The reason he implemented this tool >>is the available one is not compiled >>any of OS(?). >> >>He said quite positive things about the job >>RIPE NCC is doing maintaining the >>Routing Registry and hoped some point in US >>they will have such a well maintained >>DB. >> >>Daved Reader (Zen) mentioned RIPE NCC is doing >>a good job giving Routing Registry >>courses that help people to understand why and >>how they maintain Routing Registry DB. >> >>o IP TV panel >> >>There were panelists from IX points to discuss >>the future of IP TV situations. >>With the available bandwith and architecture >>IXs are not ready to handle such a >>big traffic. Some English attendees brought about BBC and it's IP TV effort. >> >>o BGPlay >> >>It's the most popular RIS tool. I do not think >>it's new. I heard postive feedbacks >>about it again. >> >>o RIS services >> >>Some ideas and suggestions about RIS services: >> >>- A suggestion came to add a telnet interface on RRC boxes >>- RIS does not give the view in US, we should find a way to improve it. >>- Configure a peering session from RouteView (not a bad idea) >>- Companies are looking for some criteria like >>ASpath length to adjust their filters >>at IX points. Especially, US ones since they do >>not have RR DB in ARIN area. I do >>not know how RIS can be useful in such effort. >> >>AOB >> >>o KIX (Korean Internet Exchange point) is biggest IX point, traffic vice. >>o AMS-IX is the biggest IX point, number of members, heading ahead LINX >>o LINX or LINX members are not so keen on PeeringForum, they did not >>sponsor it this year. There was not any LINX >>employee tt Peering Forum this year. >>o Jay Adelson (founder) left Equnix. He is a >>spokesman for Equnix for a while. >>He has his own compnay, digg.com. >>o There is a new content provider in the market >>like Akamai, Limelight. They are >>growing quite fast. They are happy to donate free transit to K-anycast. >>o AMS-IX and France Telecom are the only one >>who provides 10G ports. The other >>IXs are putting some effort to provide 10G ports, as well. >> >>Regards, >>Arife Vural > >------------------------------------------------------------------------------ >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 >------------------------------------------------------------------------------ > >1160438400. Watch this space... ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 1160438400. Watch this space... From wilhelm at ripe.net Fri Mar 31 16:38:35 2006 From: wilhelm at ripe.net (Rene Wilhelm) Date: Fri, 31 Mar 2006 16:38:35 +0200 (CEST) Subject: [ris-int] Fwd: RIS things, was Re: [np] Conf report: Peering Forum In-Reply-To: <7.0.1.0.2.20060331144644.034841d8@ripe.net> References: <7.0.1.0.2.20060331144644.034841d8@ripe.net> Message-ID: On Fri, 31 Mar 2006, Henk Uijterwaal wrote: > > 2. Geoff showed all kinds of activity plots Some of them are related > > to the hotspots and BGP update plots that we have. was that his presentation on growth of the routing system (prefixes, ASes _and_ update activity) in 2005? He also flashed that at PAM. Quite nice. RIS has a lot of information, but we aren't very good in pushing the info out,making network operators aware. MyASN 1.0 was a good start, but has gone into zombie state after the restructuring (less and less people in SED to do more and more work). > I tried to find > > them in the meeting but failed. Slightly related: a few weeks ago, > > Rene reported that some of the standard plots had not been updated > > since December. That means that nobody looked at them for two > > months. Which means that they are probably not too useful and we > > should consider using the CPU cycles for something else. Those were from the RISreport. Kind of like TTM, you only look at them when you feel something is wrong. I don't believe CPU is an issue. > > Perhaps we should review the standard set of RIS plots that we > > produce, remove what is never used, add new plots and make it a > > bit easier to find. the last part is most important. The whole RIS web site could do with restructuring to make it clearer what information is out there, where to find it. Marketing and Communications .... I learned at PAM that RIS data are much appreciated by the research community. Even U. of Oregon researchers acknowledge that for some analyses RIS has better data than routeviews. However, I have a feeling we are loosing touch with the NOC community, the RIPE NCC members. From Geoff's talk it's clear some folk don't have a clue what effects their poking with BGP traffic engineering has on the global routing system. Maybe the training department should expand the Routing course with a long section on "how to use the RIS"? Without continued education, RIS DB and related services will only be used by small subset of technically inclined, curious individuals. -- Rene