- Ris-int - mailman.ripe.net

Fw: NCC#2005030185 [Re: Request for BGP Data]
by RIPE NCC RIS 04 Apr '05

04 Apr '05

I will offer him to have peer rrc00 or rrc03. Is that OK? Arife ----- Begin forwarded message ----- Date: Tue, 29 Mar 2005 12:52:00 -0600 From: Dave Deitrich <deitrich(a)cymru.com> To: RIPE NCC RIS <ris-request(a)ripe.net> Subject: Re: NCC#2005030185 Request for BGP Data Cc: Team Cymru <team-cymru(a)cymru.com> Message-Id: <d8fbe6c398357cfe9884421b75fc8394(a)cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 24, 2005, at 4:01 AM, RIPE NCC RIS wrote: > As you may already know, we have rawdata available on RIS Web site. > We collect BGP updates and the snaphost of RIB (3 times a day, bview > files). I'm just wondering those RIB dumps will help you or not. If > not, > could you give us more detail what kind of applications you are > planning > to implement, and also which RRCs you like to peer with. Greetings RIPE, Thank you very much for your reply. Most of our scripts are geared towards accepting data from live BGP feeds so we would generally prefer direct peering over RIB snapshots. Also, we like to monitor for anomalies on a near real-time basis so only seeing snapshot data 3 times a day is not really ideal for our needs. We use the BGP data to track the stability of critical infrastructure, such as the DNS root and gTLD name servers. One example of our monitoring is available on our DNS page at the following URL: <http://www.cymru.com/DNS/dns.html> We will send out alerts to certain folks when notable events occur; for example, when the actual BGP information does not match with the expected BGP information for a particular root nameserver. We also use the data to provide some interesting BGP statistics on our BGP monitoring page. <http://www.cymru.com/BGP/index.html> This includes the tracking of bogon prefixes, bogus ASNs, and a few other statistics. <http://www.cymru.com/BGP/robbgp-bogon.html> <http://www.cymru.com/BGP/asnbogusrep.html> Mostly we use the data to provide free insight to the wider community. This insight is both "push" and "pull," in that we send email alerts to those who subscribe to an automated alert service. This provides them with instant notification of bogon prefix announcements, bogus ASN leakage, and prefix hijacking. Obviously with more BGP feeds we get a wider view of the internet and are able to provide better insight to the Internet community. This is why we have been contacting people and asking if we could peer with them for visibility into their BGP data. If you are interested in helping us we'd love to peer with as many RCCs as you're willing to give us access to. If you have any additional questions please let us know. Thank you for your consideration. - -- DAVE DEITRICH deitrich(a)cymru.com -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQkmVx0iQQdywQH32EQLJJgCfUTBFRjDtcmyDJC3S2p5hDPKs42QAn3Jv 8zCTRqsmVwQHIK2tyX++9oar =FBbt -----END PGP SIGNATURE----- ------ End forwarded message ------

1 0

Fw: NCC#2004081420 [Re: RIPE beacon request!]
by RIPE NCC RIS 04 Apr '05

04 Apr '05

FYI ----- Begin forwarded message ----- Date: Thu, 24 Mar 2005 17:13:04 -0500 From: Hitesh Ballani <hitesh(a)cs.cornell.edu> To: RIPE NCC RIS <ris-request(a)ripe.net> Subject: Re: NCC#2004081420 RIPE beacon request! Message-Id: <1111702384.25482.28.camel(a)devilman.u.cs.cornell.edu> Hello Arife, > I was thinking to contact you about the latest change in Beacons. I hope > you noticed that. We were running out Beacon prefixes, and got new big > block from RIPE, and replace the previous ones with new one. > > Latest changes are here, > > http://www.ripe.net/projects/ris/docs/beaconlist.html Yep, I noticed that .. thanks! > About your request, I have to discuss with my colleagues and get back to > you. Sure! > BTW, do you have any results online about your previous experiement? It > would be nice to look at it. Lorenzo, a colleague of mine, is also doing > somework about anycast root servers. Its great to hear that other people are interested and working on anycast too. In the intervening weeks (months?) since we last talked, I have done a bunch of anycast measurements. Most of the earlier measurements were to support of our anycast architecture proposal (http://www.usenix.org/publications/library/proceedings/worlds04/tech/ballan…). Attached is our subsequent submission to SIGCOMM (please do not forward the paper outside your group) - section IV.A and IV.D describe those measurements. Beyond this, we realised that it would be good to do a detailed measurement study of current anycast deployments (i.e. DNS root-servers and AS-112 servers). This study was conducted over a period of 3 months. I summarize our main results here: 1. That anycast, as deployed today, is quite poor at selecting the closest server in terms of latency. We think we know why, and that it can be fixed, but nevertheless that is what we see. (Section IV.D of our SIGCOMM paper) 2. That anycast is quite good in preserving affinity - during the period of the study, I maintained a web-site which showed my latest results (http://www5.cs.cornell.edu/~hitesh/anycast-g2.html). This disagrees with data from a study done by the operators of J-root who argued against running connection oriented services on top of anycast based on their measurements. Hence the need to do a wider scale study and this is why i need your cooperation. We plan to describe these in a measurement paper and submit to IMC in May. It would be great to see what you guys are interested in and maybe I can help you out. -- Thanks, Hitesh p.s. the above description is highly condensed - feel free to ping me if you have any questions/comments. > Regards. > Arife > > On Thu, 10 Mar 2005 03:56:08 -0500, Hitesh Ballani wrote: > > Hello Arife, > > > > Thanks for your help with my last experiment - but I need an even bigger > > favor now. I am going to describe my requirements below - if you do not find > > them feasible, please feel free to tell me so. Also, if you have stopped > > leasing out beacons to external researchers, I totally understand. > > > > I need a prefix to be advertised to many RRCs (as many as possible) for the > > duration of a week or so. However, this time I also need the RRCs to run a > > nameserver and answer queries for a particular domain. My friend here at > > Cornell owns a domain name (guha.cc) and hence, I can point anycast.guha.cc > > to the anycast address you assign to me. So for example, assume you assign a > > prefix a.b.c.0/24 to my experiment and it is advertised by 8 RRCs. I want all > > the 8 RRCs to run a nameserver and answer DNS queries (type A) for > > anycast.guha.cc - each RRC will answer with a different address. Hence, the > > first RRC will answer with a.b.c.1, the second with a.b.c.2 and so on. The > > purpose of this is that such an arrangement allows me to use thousands of DNS > > servers which have recursion enabled to perform my measurements and hence, > > adds a lot of value to my anycast study. The above mentioned approach for > > measurement is known as KING and was developed at U.Wash (described here > > http://www.cs.toronto.edu/~stefan/publications/imw/2002/imw.html). > > > > In case this sounds vaguely feasible, I would be more than happy to give you > > more details or clarify any doubts you may have. We have used the King > > approach for anycast measurements against the anycasted root-servers - and > > so, have some sense of what is required. You might have security concerns > > regarding running a name-server on your RRCs. I think there are standard > > techniques (eg. running BIND in a chroot JAIL) by which we can ensure that > > this experiment does not add any vulnerabilities to the RRCs - again, I can > > provide with more information/help in case you are interested. > > > > Thanks for your time, > > Hitesh > > ------ End forwarded message ------

1 0

Fw: NCC#2004081420 [RE: RIPE beacon request!]
by RIPE NCC RIS 04 Apr '05

04 Apr '05

Hi guys, What do you think about this request? James, what does OPS think to run named on RRCs? Arife ----- Begin forwarded message ----- Date: Thu, 10 Mar 2005 03:56:08 -0500 From: "Hitesh Ballani" <hitesh(a)cs.cornell.edu> To: "RIPE NCC RIS" <ris-request(a)ripe.net> Subject: RE: NCC#2004081420 RIPE beacon request! Message-Id: <2EE48095D8C21643B0B70EC95F9BFBAF0A3174(a)EXCHVS1.cs.cornell.edu> Hello Arife, Thanks for your help with my last experiment - but I need an even bigger favor now. I am going to describe my requirements below - if you do not find them feasible, please feel free to tell me so. Also, if you have stopped leasing out beacons to external researchers, I totally understand. I need a prefix to be advertised to many RRCs (as many as possible) for the duration of a week or so. However, this time I also need the RRCs to run a nameserver and answer queries for a particular domain. My friend here at Cornell owns a domain name (guha.cc) and hence, I can point anycast.guha.cc to the anycast address you assign to me. So for example, assume you assign a prefix a.b.c.0/24 to my experiment and it is advertised by 8 RRCs. I want all the 8 RRCs to run a nameserver and answer DNS queries (type A) for anycast.guha.cc - each RRC will answer with a different address. Hence, the first RRC will answer with a.b.c.1, the second with a.b.c.2 and so on. The purpose of this is that such an arrangement allows me to use thousands of DNS servers which have recursion enabled to perform my measurements and hence, adds a lot of value to my anycast study. The above mentioned approach for measurement is known as KING and was developed at U.Wash (described here http://www.cs.toronto.edu/~stefan/publications/imw/2002/imw.html). In case this sounds vaguely feasible, I would be more than happy to give you more details or clarify any doubts you may have. We have used the King approach for anycast measurements against the anycasted root-servers - and so, have some sense of what is required. You might have security concerns regarding running a name-server on your RRCs. I think there are standard techniques (eg. running BIND in a chroot JAIL) by which we can ensure that this experiment does not add any vulnerabilities to the RRCs - again, I can provide with more information/help in case you are interested. Thanks for your time, Hitesh > -----Original Message----- > From: RIPE NCC RIS [mailto:ris-request@ripe.net] > Sent: Monday, September 20, 2004 8:13 AM > To: Hitesh Ballani > Subject: Re: NCC#2004081420 RIPE beacon request! > > Hi Hitesh, > > > Lets start off with a prefix (I presume 195.80.238.0/24) being > advertised as > > normal (i.e. no periodic withdrawals) from 6 locations : RRC01 (Lon,UK), > > RRC02 (Paris,UK), RRC05 (Vienna,AT), RRC06 (Otemcahi, JP), RRC08 (San > > Jose,US), RRC11(NY,USA). As I mentioned earlier, the purpose is to get > > baseline measurements for an anycasted prefix when there are no flaps > (at > > least, no intentional flaps). Then, later we can introduce flaps for > other > > experiments. > > I configured on rrc01, rrc02, rrc05, rrc06, and rrc11. rrc08 is offline > by now. It's replacement would be rrc14 at PAIX, but it's not online > yet. > > > Actually, what I would like to do is to have the prefix advertised in a > > stable fashion (i.e. no intentional withdrawals) from 7 RRC locations > with > > the locations changing every couple of days .... i.e. of the 13 RRCs, 7 > are > > always advertising the prefix but the set of seven changes every couple > of > > days ...since, I would like the non-european sites (3 of them) to always > be > > part of the advertising set, so we are left with choose(13 - 3, 7 -3) = > > choose(10,4) = 1260 combinations ... while this is not certainly not > > possible, I was wondering if we could try out 5-7 odd combinations so > that > > the entire experiment finishes in a couple of weeks and then, we can > move > > onto the experiments with periodic withdrawals ... however, I am not > sure if > > this can be automated (I would be happy to write any scripts needed for > this) > > because it would be a pain for you to do this manually .. if this is > > possible, then I would be more than happy to send you a chart of the 5-7 > sets > > of 7 RRCs, each set advertising the prefix for 2 (or whatever u are > > comfortable with) days .. However, if this is not feasible, then we > could > > start with the pattern mentioned in the previous paragraph and make 1 or > 2 > > changes (2 weeks, one change a week gives us 2 combinations to try out). > > Comments?? > > I do not have any comments by now. Should think about it. > > Thanks for offer. We will see how much of time is required from our side. > Then, we can do something about it. We have already some scripts that > do the config changes on zebra/bgd. We can modify that one. > > > > > By the way, are you going to set up interfaces on these machines so that > I > > can also do end-to-end experiments? > > I've configured an interface on those RRCs, IP address, 195.80.238.1. You > can try to ping that address. In a few minutes, I will send an e-mail to > those IXs mailinglists also to allow transit that prefix. > > Regards. > Arife ------ End forwarded message ------

3 2

LFT traceroute & RISwhois
by Rene Wilhelm 22 Mar '05

22 Mar '05

Following last week's thread on nanog re: "traceroute with asn" the author of LFT traceroute, Victor Oppleman, approached me offering to add riswhois lookups to the next version of LFT. (see attached e-mail). Replacing "one-connection/one-query" lookups to RADB by lookups to RISwhois was done in a jiffy, but recognizing the potential of RISwhois, he continued spending time adding support for bulk queries (all queries over one connection) In this process it turned out there was a need for an additional riswhois option: a "-1" flag which restricts the output to one and only one route object per prefix. In combination with -M this flag ensures LFT receives at most one origin for each IP. Having checked various prefixes on the Moas page (http://www.ris.ripe.net/moas/moas.html), it does make sense to report only 1 origin for each IP: most of the time the second origin is either one with a handfull of ris peers, or a private AS. As the required modifications in riswhoisd weren't too difficult and I wanted to keep the momentum going ("het ijzer smeden als het heet is"), I took care of adapting riswhoisd last sunday and for testing purposes started it on halfweg's port 4444. Of course, I overlooked the default deny-all firewall rules, so had to wait 'till monday for Ops to punch a temporary hole to allow Victor to test his LFT-with-RISwhois development. (thanks Emil!) All tests were succesful, so now it's time to follow a proper installation procedure for new riswhoisd (will create a ticket with ris(a)ripe.net for that) Last but not least, I leave you with this quote from Victor: [...] I have things to attend to also, but I was just excited seeing as though the RIS is a cool (very cool) service/infrastructure and I think it may be the most trustworthy way of attaining this information with regard to the LFT user community. I really appreciate what you guys have done and I'm glad we can interoperate. -- Rene ========================================== From: Victor Oppleman <victor(a)oppleman.com> Subject: LFT & RISwhois Date: Tue, 15 Mar 2005 15:48:16 -0700 To: wilhelm(a)ripe.net Hi Rene, I just saw this note (a friend just forwarded to me). The new (as yet unreleased) version of LFT supports querying not only the RADB/IRR (formerly the default when using the -A (asn lookup) option), but also the pWhoIs project (sounds like the same thing RISwhois is doing--we wrote one too) OR Cymru (another source of prefix-based whois data). If you're using pWhoIs or Cymru, it's *really* fast because it can grab the ASNs in bulk (one connection/query) instead of one connection per each query. If you'd like, I'm happy to code in an option to use data from your project (RISwhois), I just hadn't heard of it yet. Does it support bulk queries or should I do it like I do with RADB/IRR and hit it once for each query? Thanks! > From: Rene Wilhelm <wilhelm(a)ripe.net> > Date: Tue, 15 Mar 2005 05:57:03 -0700 > To: <bep(a)whack.org> > Cc: Ziggy David Lubowa <ziggy(a)trueafrican.com>, Joe Shen > <joe_hznm(a)yahoo.com.sg>, Raymond Dijkxhoorn <raymond(a)prolocation.net>, > NANGO > <nanog(a)merit.edu> > Subject: Re: Traceroute with ASN > > > >> | Doesnt look like you have to, below is the link to the tarball >> | >> | http://oppleman.com/dl/?file=lft-2.3.tar.gz >> | >> >> >> According to the doc, it relies on RADB for its info, so it *might* >> not be >> as accurate as an actual BGP feed. > > Indeed. That's why we've created "RISwhois" [1], a whois interface to > the BGP data collected by RIPE NCC's RIS project [2]. You query > riswhois.ripe.net like you'd query whois.ra.net, but the data > returned are from active BGP feeds, not manually registered objects. > > Since RISwhois uses the same format as RADB, it's trivial to have lft > consult the RIS BGP tables: simply replace the string "whois.ra.net" > by "riswhois.ripe.net" in the whois.c file and recompile. > > -- Rene > > [1] > http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-eof- > riswhois.pd > f > > [2] http://www.ripe.net/projects/ris/index.html > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rene Wilhelm RIPE Network Coordination Centre > Email: wilhelm(a)ripe.net Amsterdam, the Netherlands > Phone: +31 20 535 4417 Fax: +31 20 535 4445 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Fw: NCC#2005030185 [Request for BGP Data]
by RIPE NCC RIS 21 Mar '05

21 Mar '05

Hello all, What do you think about this request? Cheers, Vasco ----- Begin forwarded message ----- Date: Tue, 1 Mar 2005 19:17:02 -0600 From: Dave Deitrich <deitrich(a)cymru.com> To: rispeering(a)ripe.net Subject: NCC#2005030185 Request for BGP Data Cc: bruce.campbell(a)ripe.net, Rob Thomas <robt(a)cymru.com> Message-Id: <9c251485ff037119c294a661ebc8f84c(a)cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, My name is Dave Deitrich and I'm a member of Team Cymru (http://www.cymru.com). We were wondering if it would be possible to establish a BGP peering session with you in order to receive copies of some of the routing data that you use for the RIPE RIS project. The prefix data will be used to help enhance our Internet monitoring utilities. These utilities look for general aberrations such as routing instability, worm outbreaks, prefix hijackings, etc. so the more peering data we have the better. We recently posted a request for more peers to a security list and Bruce Campbell suggested that you might be able to help us. If so we would love to discuss this with you. Please let us know if you think that this would be feasible. Thanks very much for your attention. - -- DAVE DEITRICH deitrich(a)cymru.com -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiUEXkiQQdywQH32EQJnQQCg5Zhq+yGLvrkGpTfPcqA8G1h/vrQAoIY8 77nM12Obk8qE4o1+Dtj9jD1W =9cP9 -----END PGP SIGNATURE----- ------ End forwarded message ------ --

5 9

Re: [ris-int] Fw: NCC#2005030185 [Request for BGP Data]
by Rene Wilhelm 17 Mar '05

17 Mar '05

> I have the concerns Lorenzo pointed. We say our peers we just set up peering > sessions to collect BGP data, and not to pass any other peers even if it's > research purpose. I don't see that as an issue; in terms of data disclosure, it hardly matters if you pass the routing information via eBGP or via RIB dumps/updates. BGP feeds will even give them less data. > My feelings say that just tell them to no, and point them to use RIB snapshots. They probably just want to add RIS peering sessions to the 17 they already have and use their existing tools to prepare reports and (quoting the original message) "look for general aberrations such as routing instability, worm outbreaks, prefix hijackings, etc." RIB dumps and updates would require special processing, more difficult to use in their analysis. I don't think setting Team Cymru up with feeds will hit back on us, on the contrary, if we would not set them up, we could be seen as being overly possesive, not wanting to collaborate. However, I do agree with Henk that we should insist on being given proper credit. Looking at http://www.cymru.com/BGP/ there's no information whatsoever on who are 'donating' Team Cymru's current 17 eBGP peering sessions. -- Rene

1 0

Re: NCC#2005030185 Request for BGP Data
by RIPE NCC RIS 16 Mar '05

16 Mar '05

Hello Dave, Thanks for your e-mail. We are discussing this request internally. We will let you know as soon as we have some more information about it. Best regards, Vasco Asturiano -------------------------- Software Engineering Dept. RIPE-NCC On Tue, 1 Mar 2005 19:17:02 -0600, Dave Deitrich wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Greetings, > > My name is Dave Deitrich and I'm a member of Team Cymru > (http://www.cymru.com). We were wondering if it would be possible to > establish a BGP peering session with you in order to receive copies of > some of the routing data that you use for the RIPE RIS project. The > prefix data will be used to help enhance our Internet monitoring > utilities. These utilities look for general aberrations such as > routing instability, worm outbreaks, prefix hijackings, etc. so the > more peering data we have the better. > > We recently posted a request for more peers to a security list and > Bruce Campbell suggested that you might be able to help us. If so we > would love to discuss this with you. Please let us know if you think > that this would be feasible. > > Thanks very much for your attention. > > - -- > DAVE DEITRICH > deitrich(a)cymru.com > > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.1 > > iQA/AwUBQiUEXkiQQdywQH32EQJnQQCg5Zhq+yGLvrkGpTfPcqA8G1h/vrQAoIY8 > 77nM12Obk8qE4o1+Dtj9jD1W > =9cP9 > -----END PGP SIGNATURE----- --

1 0

nice site
by Arife Vural 15 Mar '05

15 Mar '05

Just saw this site, it's pretty good. Maybe, we should ask them to create links for RIS tools. RIS Looking Glass is already there. http://www.bgp6.com/tools/ Arife

3 2

RIS meeting on Mon
by Arife Vural 13 Mar '05

13 Mar '05

Hi, Does anybody have any agenda item for Mon? Arife

1 1

experiments on AS-sets cancelled
by Giuseppe Di Battista 07 Mar '05

07 Mar '05

Dear all, I am sending this e-mail with the purpose of stating the position of the Computer Networks Research Group (in the following CNRG) at Roma Tre University about the AS-SET experiments. This mail covers only organization issues and is not on technical stuff. We shall address technical problems in a separate e-mail in the next few days. Until now, the relationship between RIS and CNRG has been maintained by Lorenzo. We have complete confidence in Lorenzo and he will continue to be the interface between our two groups. This e-mail does not intend to bypass him. 1. A group of researchers at CNRG, including Lorenzo, has developed new techniques for network discovery, at BGP level. Several experiments have already been done in the labs and in the ipv6 network. 2. We were interested in carrying on experiments on the ipv4 network. 3. Lorenzo discussed the issue with people at RIS. There was an agreement to use 84.205.73.0/24 and 84.205.89.0/24, originated in AS12654, for the experiments. 4. Around Feb 20 Lorenzo prepared an e-mail to be sent to a couple of mailing lists announcing the experiments. The e-mail was explicitely approved by, at least, Henk, Arife, Shane. 5. The e-mail was sent on Feb 25 to a large audience. There were a few reactions. 6. We scheduled the experiments for Feb 28- Mar 1. 7. Since we knew that the experiments could have been perceived with some suspect from the network operators, we decided to be more cautious than the RIS itself. Hence, we asked further advice by calling people at RIS on Feb 28. The answer was essentially: "people shouldn't get upset". Also, we decided to post an even more explicit message on the nanog mailing list. 8. There were many reactions, most negative. 9. Henk decided to stop the experiments. I fully agree with the decision. I do not agree with the contents of the e-mail that was sent at nanog. In my opinion the e-mail put in a bad light Lorenzo, CNRG, and RIS: - Lorenzo was presented as an "overenthusiastic student" that behaves irresponsibly. This is clearly not true (see above). - CNRG and RIS are presented as a light-heart organizations that put extremely important issues in the hands of a student without control. I also disagree on the method. Since Lorenzo was in charge of announcing the experiments, he was the one to announce their cancellation. Sincerely, Pino

2 2

Re: URGENT Re: Heads up: Long AS-sets announced in the next few days
by Lorenzo Colitti 04 Mar '05

04 Mar '05

[ris in CC field changed to ris-int to avoid replies being ticketized. Also CCing my co-authors in Rome] Daniel Karrenberg wrote: > If there is resistance like that, even uninformed resistance, we > cannot push things like this. I agree. Obviously the NCC is the least appropriate entity to push anything in the face of the community, since its charter is to do what the community wants it to do. And since it will be AS12654 doing the announcements, the buck stops here. I do think that Henk's message lacked finesse though. This is not me being overenthusiastic, this is a serious research project from a group with a proven record in the field of network discovery and a history of providing useful services to the community. Of course you can debate whether it is a good idea or not; every new technique has its fair share of detractors. And we wouldn't have gone ahead with the experiments in the face of such resistance either. But writing this off with a simple "On this occasion, he became a bit overenthusiastic though" is a little demeaning of the group's work. Anyway, with that behind us: > I beleive you should compose a very well drafted message explaining exactly > > - what we are proposing to do > - what effects we expect > - why the effects people are concerned about will not occur > > and ask for comments. This message should be OKed by Henk and maybe it > would be good to have it signed by both Henk and Lorenzo. We should do > this relatively quickly but without loosing the "well drafted". I would be happy to do this if you think it stands a chance. The issue I fear is that people in favour or neutral to these experiments won't reply to the thread and only a (possibly small number of) more conservative and/or uninformed people will be quick to criticize and opt-out. How much detail do you think we need? Do you think that to convince people we need to describe all our algorithms (some of which we haven't even fully developed yet), or do you think a more general description would be enough? Of course we would still provide much more detail on the principles we want to use and how we are trying to accomplish it. Cheers, Lorenzo

3 2

Re: [ris-int] Re: NCC#2005024029 query parameters missing from RIS cgi URLs
by Rene Wilhelm 03 Mar '05

03 Mar '05

> > indeed, a good and easy way to get the URL, but perhaps a few extra words > > that the copy should be done via browser's popup menu? > I have not introduced pop-up menus for the RIS, by now. I prefer to > leave it like that, later if we will get any feedback or questions > about it, then we could add pop up or more explanation either help > pages or the form itself. no, no, I was not talking about pop ups done by RIS website; only about the menu that appears when right clicking on a URL, the one where you can choose "copy link location". I thought of mentioning something like "copy ... using right mouse button" But then again, this is only my view; now that I know how to copy, it's fine with me. Maybe other users don't have problems and are already experienced in copying URLs this way? -- Rene

1 0

Re: [ris-int] Re: NCC#2005024029 query parameters missing from RIS cgi URLs
by Rene Wilhelm 03 Mar '05

03 Mar '05

>> but _how_ do you copy the link from the bottom? the left mouse button >> just takes me to a new risearch-result.html page. Am I overlooking something? > I do not know how to copy from the bottom of the page, I do not think > here is a way to do .. > was talking to go "Copy the link" and click "the link" with left button > and choose "Copy link location" option and copy the URL. ah, but that's the *right* button for me! :) indeed, a good and easy way to get the URL, but perhaps a few extra words that the copy should be done via browser's popup menu? -- Rene

2 1

Re: [ris-int] Re: NCC#2005024029 query parameters missing from RIS cgi URLs
by Rene Wilhelm 03 Mar '05

03 Mar '05

>> The links to IPv6 RIS DB queries from RISwhois work like a charm, >> even when cookies were still blocked :-) >> > Hm, I'm using another module WWW::Mechanize to run risearch for > riswhois. It looks it's doing something strange. isn't it that in the case of riswhois, the query is done by halfweg, so no need to set a cookie in user's browser? >> The risearch-result page includes the line "Copy the link ..." >> and when you point the mouse to it, you see first part of the URL >> in the bottom of netscape's window, but when you click on it, >> the query gets executed and you again get a risearch-result page. > With Firefox it looks ok, gives all the URL at the bottom. I thought > it would be more convenient for user just click left mouse button, > and copy the link if they like to get the URL. but _how_ do you copy the link from the bottom? the left mouse button just takes me to a new risearch-result.html page. Am I overlooking something? -- Rene

2 1

Re: NCC#2005024029 query parameters missing from RIS cgi URLs
by Rene Wilhelm 03 Mar '05

03 Mar '05

Hi Arife, > I made those changes you asked for including RISwhois and Cookie check. > Please have a look and let me know if you would have any comments. The results in the case blocked cookies is short and to the point. perhaps the standard header and footer should be added to the page, but the message itself is clear, no confusion possible. The links to IPv6 RIS DB queries from RISwhois work like a charm, even when cookies were still blocked :-) As for the referencing URL, that's still a bit problematic. The risearch-result page includes the line "Copy the link ..." and when you point the mouse to it, you see first part of the URL in the bottom of netscape's window, but when you click on it, the query gets executed and you again get a risearch-result page. Persistent users can find the URL by checking the source of the page (so a big improvement already!), but perhaps it's a bit more user friendly if the "copy the link" part would take you to a page which lists the /risearch.do URL instead of executing it? -- Rene P.S. Don't forget to announce the new CGIs when you're finished; Some folk out there will be happy to see IPv6 queries to the RIS DB are now possible!

2 1

Re: NCC#2005024029 query parameters missing from RIS cgi URLs
by RIPE SW Bugs 03 Mar '05

03 Mar '05

Hi Rene, I made those changes you asked for including RISwhois and Cookie check. Please have a look and let me know if you would have any comments. Arife Link for URL with args, cookie check and On Wed, 23 Feb 2005 18:10:36 +0100, Rene Wilhelm wrote: > Hi, > > The new CGIs on www.ris.ripe.net have one important thing missing: > they do not support entering parameters via the URL and they do > not report the entered parameters either. > > For example, something like > > http://www.ris.ripe.net/perl-risapp/risearch.html?net=192.228.79.201&prefty… > > no longer works, it just comes back with the default form. > > This makes it impossible to discuss RIS results via e-mail, something we > will need and have used in the past when reporting on routing incidents > (e.g. triggered by users' request to explain DNSMon or TTM observations). > In the absence of URLs with query params, it is also difficult for network > engineers to share RIS observations with their colleagues. > > So, could you have a look and fix the CGIs? might be as trivial as > adding a method="get" to the html code. > > Thanks, > > -- Rene > > P.S. and while you're at it, you might want to run your pages through > the validator at http://validator.w3.org/ Currently, risearch.html > is not valid XHTML 1.0 Transitional.

1 0

[Fwd: Heads up: Long AS-sets announced in the next few days]
by Lorenzo Colitti 01 Mar '05

01 Mar '05

FYI: Here is a copy of the announcement I sent out to NANOG, the routing-wg, and ris-users warning them of impending long AS-sets. After discussion we felt that it was best to proceed with a little more caution. :-) Cheers, Lorenzo -------- Original Message -------- Subject: Heads up: Long AS-sets announced in the next few days Date: Tue, 01 Mar 2005 19:49:50 +0100 From: Lorenzo Colitti <lorenzo(a)ripe.net> To: nanog(a)merit.edu, routing-wg(a)ripe.net, ris-users(a)ripe.net Hi, as announced to the RIPE routing working group mailing list [1] and elsewhere, over the next few days the Computer Networks research group at Roma Tre University, in collaboration with the RIPE NCC RIS project, will be performing experiments involving announcements with large AS-sets in the AS-path. We are doing this to test innovative network discovery methodologies we developed to allow ISPs to determine how their prefixes are seen by the rest of the Internet. The announcements will be for prefixes 84.205.73.0/24 and 84.205.89.0/24 and will originate in AS12654. We have been performing similar experiments over IPv6, in collaboration with the NAMEX internet exchange, since December 2004 with no ill effects; furthermore, our announcements are standard BGP, so conformant implementations should be able to process them, and very long AS-sets have already been observed in the past (e.g. [2], [3]). However, we want to be careful to avoid router bugs on legacy devices, old firmware versions and the like, so we are first sending out test announcements with progressively longer AS-sets. Should you encounter a problem with these advertisements, please let us know and we will withdraw them. The proposed timetable of the test announcements is as follows. 2005-03-04: 14:00 UTC: 10-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 25-element AS-set 16:30 UTC: withdrawal and, if there are no problems: 2005-03-07: 14:00 UTC: 50-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 100-element AS-set 16:30 UTC: withdrawal Note: For reference, the AS-sets already observed in [2] and [3] contained 123 and 124 ASes respectively. For questions/comments, please contact compunet(a)dia.uniroma3.it or lorenzo(a)ripe.net. Regards, Lorenzo Colitti On behalf of the Roma Tre Computer Networks Research group [1] http://www.ripe.net/ripe/maillists/archives/routing-wg/2005/msg00021.html [2] http://www.ripe.net/projects/ris/Talks/0101_RIPE38_AA/sld003.html [3] http://www.ripe.net/maillists/ncc-archives/ris-users/2002/msg00044.html -- --------------------------------------------------------- Lorenzo Colitti Ph.D student Computer Networks research group Roma Tre University colitti(a)dia.uniroma3.it +39-0655173215 ---------------------------------------------------------

1 0

Announcement: Changes to RIS Routing Beacons
by James Aldridge 25 Feb '05

25 Feb '05

------- Blind-Carbon-Copy To: ris-users(a)ripe.net, ops(a)linx.net, sfinx(a)ml.renater.fr, tech-l(a)ams-ix.net, announce(a)nl-ix.net, tech-users(a)lists.gn-ix.nl, vixoper(a)vix.at, peer.tech(a)mix-it.net Reply-To: ris(a)ripe.net Subject: Announcement: Changes to RIS Routing Beacons From: James Aldridge <james(a)ripe.net> X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Fri, 25 Feb 2005 13:56:38 +0100 Sender: james(a)x34.ripe.net [Apologies for duplicate messages] The RIPE Routing Information Service has made some alterations to our BGP Routing Beacon announcements. The main changes (since 3 February 2005) are: * Beacon prefixes now come from a new, larger address range 84.205.64.0/19 (instead of 195.80.224.0/20); * We now announce an "anchor prefix" corresponding to each beacon; * For each beacon and anchor prefix there is a "pingable" target at the first address in the range (beaconNN.ris.ripe.net, anchorNN.ris.ripe.net). All prefixes announced by the RIS (AS12654) are listed in the AS12654:RS-RIS 'route-set' and individual 'route' objects in the RIPE Database and are described in more detail at http://www.ripe.net/projects/ris/docs/beaconlist.html RIS peers should set any maximum prefix limit to at least the number of entries listed in the route-set (although it is unlikely that any one RRC will ever advertise more than a small subset of these prefixes). We would also like our peers to treat these prefixes in the same way that they would a customer's prefix and announce them to their other peers and upstream providers. If you have any questions, please contact the RIS team at ris(a)ripe.net. Regards, The RIPE NCC RIS Team ------- End of Blind-Carbon-Copy

1 0

Re: [NCC#2005024029] RIS CGIs are online
by Rene Wilhelm 25 Feb '05

25 Feb '05

Hi Arife, >> I also have a request: once the prefix cgi is returning v6 results >> as expected, could you modify the riswhois cgi to also put up >> a "Query RIS database" button for IPv6 queries? >> James did the first versions of the riswhois cgi, but I guess that after >> the restructuring this is now SED responsibility. > Yes, you're right. I put into ToDo list. > About ETA, I can not say something definite this week. I'm second line > support for RIPE DBM, and it's bit busy. Next week I will get back to you. OK, that's perfectly fine. > Those CGIs are implemented Mason and Perl. One CGI has more than one > components. Form, result, and errors are printed by seperate html/cgi > files. We can easily pass the ARGS from one to another, but the result > page is not the one which is executing CGIs. That means if you copy and > paste and send somebody the result page with arguments, it will not work. > Since the CGI that executes the code is different than the one that > produce the results. Because of that I do not think it's not so useful > to have the ARGs in URL. > When I had a chat with Kevin about it, he suggested to add a link somewhere > on the page giving the URL. I do not know what you think about that. If > you want we can go for that. The most important thing is that by exchanging URLs people can point each other to results of a specific RIS query. Usually, you would go to the top of the browser and copy the URL there, but if that's not possible a link on the results page, something like "The URL for this query is $url" would work too. BTW, nice to see the query form is repeated on the results page! -- Rene

2 1

RIS meeting agenda for Monday
by Arife Vural 25 Feb '05

25 Feb '05

Hi guys, Does anybody have any agenda item for Monday? I do not have any particular agenda item other than RRC13. For RRC13, maybe Gerard will give us short update by e-mail. Arife

2 2

Suggested announcement for as-set stuffing experiments
by Lorenzo Colitti 24 Feb '05

24 Feb '05

Henk Uijterwaal wrote: > (I've no problems with this experiment as such. We should include > it in the announcement about the new beacons though, James?). Ok. What about the following text? It could be added to the beacon announcement, or I can whip up a standalone annoucement if you think it's necessary. (Comments welcome of course.) We also need to ask our peers to accept everything in the route-set *including ASes behind 12654* and not just ^12654$. James, could you add that to the description you are going to send to the peers? =====================8<------------------------- Beacon prefixes 84.205.73.0/24 and 84.205.89.0/24 will be used by researchers at the Computer Networks research group at Roma Tre University to perform studies on network topology discovery. The objective of the experiments is to investigate new methodologies for topology discovery and experimental mechanisms for deducing the routing policies of ISP's, the quality of their connectivity, and more general properties of interdomain topology. The experiments will involve announcing AS-sets of varying lengths behind AS 12654 and are initially scheduled for the last week of February and the first week of March. =====================8<------------------------- -- --------------------------------------------------------- Lorenzo Colitti Ph.D student Computer Networks research group Roma Tre University colitti(a)dia.uniroma3.it +39-0655173215 ---------------------------------------------------------

3 4

Re: [ris-int] RIS CGIs are online
by Rene Wilhelm 24 Feb '05

24 Feb '05

>> For example, this input: >> >> Prefix/AS: 2001:610::/32 More specific IPv6 >> >> doesn't give any results (only the error) :( > Works for me. The URL may have changed, if you're going to a bookmarked page. No, no, I was not starting from a bookmarked page; but I've found it, apparently the RIS CGIs don't work if the cookie RIPE_NCC_DB_SESSION is not set. (my parents taught me long time ago not to accept cookies froms strangers, so my default reaction to offered web cookies is to "deny"; most of the time, the cookies aren't needed at all. www.ris.ripe.net also must have ended up with cookies blocked, but until now that didn't cause problems) As there may well be others with similar settings, perhaps it's an idea to catch the error of the cookie not being set and return a user friendly error message? > > I also have a request: once the prefix cgi is returning v6 results > > as expected, could you modify the riswhois cgi to also put up > > a "Query RIS database" button for IPv6 queries? > > > > (compare: http://www.ris.ripe.net/cgi-bin/riswhois.cgi?address=193.0.0.1 > > with: http://www.ris.ripe.net/cgi-bin/riswhois.cgi?address=2001:610:: ) > > > > James did the first versions of the riswhois cgi, but I guess that after > > the restructuring this is now SED responsibility. > > Okay, we'll add it to our TODO list. Any rough ETA? It shouldn't be too difficult, presume one can almost copy and paste the relevant parts from the IPv4 case. -- Rene

2 1

RIS CGIs are online
by Arife Vural 24 Feb '05

24 Feb '05

Hi all, RIS CGIs are online with IPv6 support. Please have a look at it and let me know if you have any comments. You can get them through this page http://www.ripe.net/projects/ris/tools/ CGIs which are re-written ASInuse, PrefixInuse, Search By Prefix/AS and BGP Hot Spot Tools. Arife

2 2

TKO NOTICE: eBay Registration Suspension
by aw-confirm＠ebay.com 17 Feb '05

17 Feb '05

1 0

New RIS CGIs: no query parameters in URLs?
by Rene Wilhelm 17 Feb '05

17 Feb '05

Hi, I didn't notice until now, but all these CGIs no longer have the query paremeters in the URLs. E.g. the results of a prefix search are presented in a page called "/perl-risapp/risearch-result.html" In my opinion, this is a loss of functionality. When talking things over, sharing results with a colleague, posting once findings to a list, it is extremely useful if ris-users can just copy and paste a link containing all the parameters used in forming the query. It just doesn't work if you have to write down all the values of input fields, settings of switches and knobs. We have this for the RIPE whois, RISwhois, TTM plots-on-demand and TTM tracerouteDB CGIs. Can we have it back for the RIS CGIs? Thanks, -- Rene > Hi all, > > RIS CGIs are online with IPv6 support. Please have a look at it and > let me know if you have any comments. > > You can get them through this page > > http://www.ripe.net/projects/ris/tools/ > > CGIs which are re-written ASInuse, PrefixInuse, Search By Prefix/AS > and BGP Hot Spot Tools. > > Arife >

1 0