routing-wg

Note: Please be advised that this an edited version of the real-time captioning that was used during the RIPE 56 Meeting. In some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but it should not be treated as an authoritative record.

RIPE 56 Routing Working Group 9:00am, Friday, 9 May 2008

MACIEK WOJCIECHOWSKI: Point up to the size of the Internet today and even more. Another approach we took is start with a very simple solution. BGP is quite complex. We don't need all of it or what we actually need or start what we think we should need and I think that for this experiment we need that kind of thing so we just add them. So we have to create our simulator in a very, many black boxes that we can exchange and the thing we will have to do with this kind of simulator is calibrate, I will talk about it a bit later. I will show you the odd models, we don't [unclear] we model it. That means first of all, we simplifying everything we can, no physical network modelling. We treat, that is big thing, treat every AS as one node for now so we don't get into connection of the AS in [unclear] we are interested in the inter AS message exchanges and this part of the protocol. Then we model standard BGP announcements withdrawal messages. We have of course modelled FIB, their policies, this is kind of what BGP, what BGP really is. You receive a messages you update FIB back into policies and propagate your neighbours. We do have specific BGP tables so every quasi-router knows all the prefixes. This is quite a lot because we have 27,000 ASes, each all prefixes for 250,000 prefixes, it's a lot and very important for the experiments part of this [unclear] there has to be a lot of freedom for particular node behaviour, there has to be possibility to change behaviour of every node in a way that would be need sod seal the black box approach. Different from policies and build every node out of the boxes. And this calibration I mentioned is that when you are emulating, simulation it's kind of get out of hand. We don't have 100 percent control of what is in fact getting similar laid so we have to calibrate it so that it really resembles the BGP behaviour we observe in the real world. To do that, we need some real world data. There are some scenarios that are known that BGP behaves this and that this and our task right now is to make our simulator behave in the same way. There is for example, there are risk updates known so the updates are exchanged between the serves. If we know the root causes or who is responsible for update that is coming we could run our simulator on those root causes and see and see whether, for example, the average path is the same because the average path won't be the same if the we don't know the policies that are happening, that ASes are using. Still we have network that might be enough. We are not full ourselves, we know our calibration won't give us the same level. Even driven simulator is actually better, some of them they don't scale and we want it to scale. This is price we have to pay for the scaling.

And few things about our software. What we have is Java based simulator. It's running on homogenous cluster. Running on 80 compute nodes with four course each for 27,000 ASes, they just run in normally, it's Java scheduling the ASs, not some magic not as in give us something like 350 per computer node and it works pretty well actually. We what they provide is list of ASes with relations between them. This is simply provider customer and [unclear] can relations and we store prefixes on hard drive, too many even with 80 machines for Gig each, there is too much data to store it in memory. Store hard drives and do our best not allow to interfere with our simulator and we are propagating the prefixes from the BGP table so it is something like for each AS we take one point, we have kind of real New York and propagating to simulate the current Internet. And just few numbers, how good it works. It's 500 milliseconds to fully propagate the prefix that was not known, that was not known before. So just one AS announce as new prefix and takes 500 milliseconds to propagation fully stops. If we run it just let them go as far as we can without any timers. If you propagate BGP announces with one prefix in only one prefix in each announce, the simulator can digest something like 2000 messages per minute and put more prefixes in a BGP announced message up to 15,000 prefixes per minute. So to get from scratch, to the time that everybody knows the whole table for 250,000 it takes something like 17-18 minutes and it's reasonable well they have that time. The and the other way you can store the current state of the simulator, everybody every node will store the FIB and [unclear], 100 Gig bites for all of the nodes. So it's actually easier to simulate it from scratch than allow this 100 big bite data. What we would like to do is write some kind of easily extendable scenario framework so you can write most probably nice XML file, you would like to put those measure those things, which events are triggered by which event and what you like to measure, something like how many benefits I have received, what is the average path convergence time and so on and more important thing actually, is to try to gather as much reload data as possible. This is what would you like from you we would like to show this is a valid BGP plod he will and approach is [unclear] and everybody that would like to use it in the future, that it actually simulates BGP and not just writing something. Like to you collaborate with us. If you have any kind of data that is, if you have route causes for some kind of computated root causes for updates that are seen by RIS routers, they would be perfect. If you have signed of scenario that BGP behaves in this way. We know some things but maybe you know [unclear] have a thing which you help us ideas what can be simulated with this kind of approach. Looking at the BGP at global perspective. We are look mostly at, every time we have to look at numbers and averages, not of AS path itself because they won't match but many characteristics will so you can simulate very much [unclear] like the you can really see how the effects the amount of message that are sent. [unclear] helps because I am personally not so much and this is the kind of thing you can do. Put a timer and see how it effects the number of messages. And just grab me here, ask a question, grab me during the lunch or send us an email. Be part of it. Are there any questions?

CHAIR: No questions. OK. Well, thanks for presentation and I encourage you to send updates on project to the routing mailing list as you make progress on it. And like thank you very much.

(Applause)

Next is Eric.

ERIC ROMIJN: Hello good morning, my name is Eric. I work for the RIPE NCC I am a software engineer there in information services department. I am going to talk about the routing information service and a new service from our department which is IS alarms. I will start with a short introduction and update on what we have been doing and then get into IS alarms.

So, what is RIS? It's routing information service and it's often summarised as a looking glass with history. We collect data from now 620 peers around the world on 15 different collectors. We peer from our own AS and everything we get from them we store in a large database. Then, there is a set of query tools on our website where you can query all this data. We keep all the raw data in a binary format for which we provide to and library to read it, we don't disregard it we have everything started 1999. We generate a number of statistic reports based on our data and we have a notification system called MyASN which is someone can announce you when someone announce your prefix. We have 15 collectors, mostly in Europe now. There is a new one in Miami hosted by Terremark, thank you for that. And TERRE and connectors to map of the Americas Internet exchange.

So what we have been doing: Since last meeting, we have been focusing on performance and architecture improvements. A lot of stuff in RIS has been built when it was still a lot smaller. So, it runs on a bit, the hardware is nearing end of life cycle, the database designed can be improved, we want to build a better internal API and have faster resilience against failures. So, current progress is we do actually run RIS on new database service now. We don't have any very careful benchmarks yet but we estimate this to be 20, 30 times faster than the old system, depending on the queries. Also, we have a new database design, which will be a lot more efficient and, therefore, also will improve the speed. And work is being done on a new API, which will handle all traffic to RIS.

So, MyASN is the alarm system in RIS. It will notify you if someone would announce your prefix. If you have an account and set up the filters correctly, or if someone else gives an expected trend set to your prefix or to a prefix of your customer. If it sees such a thing it will notify by sys lock log or email. So some idea of the sites, we have 1285 registered users. Together they have configured more than 2000 alarms, of which almost 1,000 have been triggered at least once. If we look at the growth in MyASN accounts since 2004, we add about 20 MyASN accounts every month. Anyone who has an AS can register an account, you don't like to be an LIR, it doesn't have to be RIPE region. So you can see a small jump in January, that is when the YouTube incident occurred and people thought that it might be a smart idea to monitor Thor these kind of things, which MyASN would catch. RIS is we have more services. TTM does it when it sees strange delays, DNSMON might have it in the future. And of course, the systems are now all separate which makes them harder to maintain, so we have built a new system called IS alarms which connects everything we have of data feeds together, where you can configure filters and then use a number of outward plugins. This means instead of having multiple different interfaces, we now have a single interface where you can see all your alarms that are configured with the system, switch them on and off, see how they have been triggered. We also plan to have very flexible filtering for this where you can [unclear] actually say I want the well, you can stack filters together with different requirements. Currently, we have email and syslog running there. SMS might be an option in the future but we don't know for sure yet but it's really easy now to just add an output system.

This new system will completely replace MyASN so at some point in the future, we will stop MyASN. We will probably migrate all existing alarms to the new system, but it's as long as it's not production grade [unclear] we will keeping MyASN running as is. Anyone who has an existing MyASN account can log in and try it. The core focus points of we provide a clear interface, all compared to MyASN it supports IPv6, MyASN does not. It's built to have a shorter delay between the event occurring and the alarm being sent out. And will be providing more output options.

So, a description of how it actually runs. This is my standard ASN account, it's not my real pass order, I can log in. This works for all existing MyASN accounts and I can start adding my alarm and I want to monitor it from MyASN, monitor my or [unclear] and sent email and syslog if it goes wrong, you can select any combination and I can enter a nice description, and then I can say as well, this is my prefix, it has to originate from this A [unclear] number F it does not you sent a notification to syslog and you mail me. If you have a number of alarms set up, I have a few running now, you have this overview of all the alarms you have, when you change them what kind of outwards they use and whether they are active. You can see this my RIPE meeting alarm, which is currently active and sending email and syslog. You can also click them and then you will be able to edit them. And if it actually detects such a condition it will send a mail like this where it says, originate from AS 3.7, RIPE if it's wrong they send me a mail. So, where we are looking for now, for the future, is to probably implement SMS notifications, IM is also a nice option. Also, we plan to add more input so currently it's just RIS, but TTM will be integrated in that and then we can also start looking into combined RIS and TTM filters where you can say if RIS has this and TTM has this then it's an alarm condition. Also, of course, it's currently in beta so we will probably one into a box we will have to fix.

So the beta is online now and you can see it there. So if you have MyASN account already, you can log in; if not, you can request for MyASN account and it will useable for that as well.

So there was my short talk. If you have any ideas for how we can improve this or if you find other things, mail us and we will look into it.

CHAIR: Thank you, Eric. Are there any questions for Eric at this point. I am happy you are looking at this SMS one of the problems, if someone hijacks your prefix it's quite unlikely that you will be unable to send me mail so unless you have an...

ERIC ROMIJN: That is the thing.

CHAIR: The alarm will trigger.

ERIC ROMIJN: It's one of the things I want to look at, how many people who have ASN, how many could we mail if it was hijacked. I don't know how much this effects. SMS would fix this problem and out of band system would.

CHAIR: I don't know if you can use the route collectors themselves top send outgoing messages.

ERIC ROMIJN: Not really.

CHAIR: Thank you thank you.

(Applause)

CHAIR: Next up is we have time to [unclear] proposal that was presented by Kurtis earlier in the week. We have been operating under this model where potentially policy proposal discussing the Working Group. I don't know if this is an optimal model but anyway.

KURTIS LINDQVIST: There are no slides for this as I did the presentation and I guess this slot was more given for discussion and thoughts on how to move forward on this. I am going to assume you all know what I am talking about, if not you have to go back to the video from Monday. So I don't know how to what we want to move forward with this, one thing take some more of the implementation specific discussions over to the Database Working Group. If this decides this is a good idea to go forward, and we can also sort of split this up, take it to the NCC and ask them to implement this.

CHAIR: I want to you repeat everything you said on Monday, if you could say the exact content of the proposals.

KURTIS LINDQVIST: The idea was basically, that based on the data, the RP take and build a new IRR registry, a repository that could providers could pull the data from and have as priority, if you had a route you would know it was more trustworthy because it came from this idea, basically. That was just another publishing point for the IRR.

CHAIR: OK. Do people generally understand what this is about? Like creating a new IRR?

KURTIS LINDQVIST: It's really hard

CHAIR: Similar to the one that RIPE already support but starting from a clean slate without all the contamination the current one seems to have and making sure the objects are this time around more strongly to get you through the R P T I mechanisms. There. One point the RIPE NCC would make a tool available so people could build this data by themselves. And it's really good

AUDIENCE: I am I am to blame for not having the advertisement slide wear which times is bad, really. Well OK, if really the idea of, well, okay what this is and what benefits come out of it are not really that clear, I will try to throw in a couple of key words. The RPKI stuff is something that actually has been done in initially targeting long-term goals in doing secure routing protocols, and it is obviously something very important and desirable, but the benefits of this will take several years until we get them. The RIRs have taken action in actually creating RPKI as new data structures with security, and some emphasis in this work has been more on securing the allocation data, which, of course, is the RIR's job and which is, of course, also extremely important, and in particular, in the times of address space becoming scarce. So, what I did was looking at this and thinking about, well, OK, what security practices in routing are there out in the field at the moment. It's not really much, and, well, OK, I think the current thinking is that it is not that much in particular because there is so little trustworthy data around. Actually, in the RIPE region, there is actually a relative good situation regarding good data, but, well, OK, there are other parts on the globe and some of us are operating there, as well, and, well, OK, the poor other guys, well OK, obviously also have a problems and well look at it, Pakistan Telecom and YouTube are not RIPE are not using RIPE resources. So,, well, OK, the thing that we have out there are the old IRR databases using RPSL and there are various people have various tools built for using RPSL databases and now I took a look at, well, OK, what do we get in relevant data in the RPKI for routing security and what do we have in RPSL IRR databases and the tools that everyone is using who is doing something. And it turns out RPKI has quite precisely one part of a data which is called ROAS, the route origin organisations that actually contains relevant information; all the other stuff is not truly routing relevant. And looking at taking this and looking at the RPSL side of things, it turns out we have something in RPSL that very, very precisely matches the row I can't say and that is the route objects in the RIR databases. So the idea of creating mapping the RPKI ROAS that are supposed to be very secure, very trustworthy and create an RPSL representation office and have the tools that are around and being used, access this data, obviously makes the RPKI data immediately useful. Now comes the question, well OK, do we have the means so that we can actually distribute and distribute via RPKI data that is mapped into RPSL and do we have means so that when our tools access RPSL data, we can actually differentiate and say, well, OK, in this particular context when I am asking for data, I want to have the trustworthy data opposed to situations where I say, well, OK, unfortunately, as has been in the past for certain things, I don't have the really high quality data and I do different selection and the means for doing this is there in RPSL, in RPSL all objects are tacked with source attributes which say from which database the object comes, and if we now do the RPKI to RPSL mapping and tag all the mapped objects with a distinct source, our tools allow us to when we want to have when we want to use specifically the trustworthy data, we can just say, well, OK, just use or prefer the data that comes with the RPKI map source tag. And overall, we can use all the existing tools with the good new data, and well, OK, there may be some interesting tasks to optimise the existing databases and tools for the particular use, but conceptually and at least for starters, to get going, we really can take the existing tools databases without no change at all, and immediately take the advantage of having certified data and, by the way, it's not only a question of being able to as a consumer of the data, as a reader of the databases, it's not only important that, as a consumer of this data, I can pull the trustworthy data; in my opinion, it is all it is at least as important for me that I can tell all the parties I am interacting with that, well, OK, if you had problems in the past to find some place where everybody expects your trustworthy data, with RPKI I can point anybody, whether the customer sits in Nepal or in Detroit or somewhere in Latin America, I can point them and say, well, OK if the RPKI is the thing whether you can trust your data is handled right, and everybody will pick it up there.

CHAIR: Thanks.

AUDIENCE: Wilfried, Database Working Group Chair. First of all, I like the idea, let me start with that one, because it just has the potential to get a little bit of the problem space sorted out eventually, maybe. The thing that makes me stand just behind a microphone here is the curiosity about the choice of word "separate IRR" [unclear] just would like to find out what this actually is meant to be. Is it to be just a separate database with a separate [unclear] or is it meant to be just something which is contained in the existing infrastructure, but with other attributes and with a mechanism to maybe filter between those having these sort of security attachments versus those which don't.

AUDIENCE: We are not intending to do any change to the objects. Don't hit me later when and I am keeping this out of this meeting when we take a look at certain optimisation things, but well, OK, there will be no additional attributes and conceptually, the data will be exactly the same and the point is, well OK, it doesn't matter whether the original database goes on to a server with a different domain name; the thing is, it will go to into the collection of the IRR and the trustworthy data will be tacked by its distinguished source tag, and the source tagged is the way to well, OK, select and, well OK, if you are a really security geek, of course you will not trust the RIPE NCC that they truly do the verification of a trustworthy data right; you always want to do it yourself, and well OK, of course you are free to do that, but, well OK, my guess is that it's very good service for the community for having the central service providers, like RIPE NCC, to provide the data and allow parties that are trusting the NCC anyway for many things, to take this.

AUDIENCE: George Michaelson from APNIC. Speaking purely in a personal capacity because I have no role in policy, I see I was very pleased that you spoke about this having really limited lifetime and limited scope, because there is a fundamental issue with models based around where you get data from, which is different from can you check the data innately as a thing in itself and you have gone directly to that in your last comment, so with that strong caveat about the inherent weakness of trusting where you fetch from and remember the data is copied routinely and people often use indirect sources of data and there are inherent problems in saying because it says source RIPE it must be good; I have no particular problem with the decision to say we should do this and there is a policy proposal in the APNIC region and if it receives sufficient support to become operational we would have no innate difficulty in running that service but I do think it's important to say, it is inherently weak to assume unverifiable data is trustable of where you get it and I believe that the work the RIPE is considering to develop extensions, to provided embedded signature support is orthogonal to this proposal, it is not harmful and is something that is good and should be done. That is all I wanted to say.

AUDIENCE: I wanted to answer translate a little bit into more simple language the answer to Wilfred. The answer is, extended route objects with a distancing source attribute in some database, and, and then maybe some extensions late every but at the moment it's standard route attributes, different source attributes and RIPE database and, actually, we are already working to get the stuff into the prototype so it's not like something very difficult. I was a little bit surprised to see this as a policy PDP proposal. No criticism, but it looks like a little bit heavy weight mechanism for something that has already been done.

CHAIR: So it is already being done.

AUDIENCE: Well, we discussed this. I put it into the process for the prototype. I am not sure where it is in the planning of the prototype. I am not that deeply involved, but they told me that the people who were doing the prototype say they can do it very easily. So it's not like we are going to do it if this room says no we shouldn't do it, but the wheels are already in motion.

KURTIS LINDQVIST: I can come back to that.

AUDIENCE: Andrei, RIPE NCC. I think there are a lot of implementation details, maybe not a lot but the RIPE NCC have to look into this. The substance of the proposal is very simple and I think the beauty of the proposal changes nothing or basically nothing, so it's a really low hanging fruit, I think we support this proposal. However, just one comment, and falling on George Michaelson's comment is that there are the components in the routing registry, right, apart from just route objects, and perhaps not now, of course, but maybe later, we should think about the general concept of routing security and how we can improve this using RPKI. There is already some thinking going on with regards to how we can improve authorisation schemes and how we can improve the quality of the data by maybe even signing the data in the routing registry to make it more reliable. Thank you.

CHAIR: OK. Well

AUDIENCE: Just once again. I also wanted to add a little comment about Rudiger's statement that there are lots of routing registries using RPSL. Thinking about the presentation yesterday and something you may see later today in the morning, it seems to be not the default case to have RPSL representation in various routing registries as they are implemented. Not all of them or not the majority of them or about half of them seem to be using RPSL as the language to represent stuff and that is the reason why I am bringing this up again here because I think if we start to improve that or try to improve that and if you want to add another set of goodies it might just as well be that is not true.

AUDIENCE: We keep it simple.

AUDIENCE: You can definitely but if there is a chance to improve the global system I would at least try to find out whether wave chance to do so.

CHAIR: This is why I asked yesterday to be a bit more specific instead of saying certain things and a few of those and some of that, the other ones, because it's good to have complete data.

I don't think it's entirely relevant to the discussion right now, let's finish this one before you get.

AUDIENCE: I actually have something on this very particular subject and I agree with Daniel in this case that the wheels are in motion on the simple low hanging fruit implementation but when we refer to specifically the proposal, it actually, if you look carefully, has five [unclear] in it going all the way down to individual ISPs or internet exchanges should be able to run the same software that we do on their side independently and so on and then we go far beyond low hanging fruit. What we are very interested in doing and supporting is this low hanging fruit and as we said that is in motion but that is just a subset of this very big proposal, keep that in mind, it's not all low hanging fruit that is discussed.

CHAIR: I would like to give a chance to anyone in the room that hasn't spoken yet to voice their opinion should it be contrary to it. So far, all the opinions have been in favour. Absent that, I would then suggest that perhaps along the lines what have Daniel suggested, we change this from a policy proposal to just a regular Working Group action item on the NCC. Since work seems to be already started.

KURTIS LINDQVIST: Because it was submit as a policy proposal to the other RIRs and it was just the same text. There wasn't a particular reason why it was PDP.

CHAIR: Would the proposals be OK with putting this as normal Working Group action item on the NCC to be worked on. Basically, to specify what those low hanging fruit are, what are the things that are being tackled first and provide us with an estimate of when that first part would be done. And then, following that, provide an assessment of what work would need to be done afterwards, and if you could get some sort of report in between now and the next RIPE meeting, that would be excellent.

KURTIS LINDQVIST: Or even running code

CHAIR: Yes. So that the hard work could be assessed and discussed during the next.

AUDIENCE: I would love to have had that input yesterday as input from other working groups.

CHAIR: OK. Noted. Thank you. We have a couple of small items.

SPEAKER: Or while I argue with the laptop very quickly, if you have any other small things you wanted to do first, by all means go ahead.

CHAIR: We were approached by from Japan by wanting to report on the status of ASN 32 implementations in different router implementation. I think he has now sent a mail to the listing list in lieu of actually coming up and presenting. Just have a look. So now you are the last one.

SPEAKER: It's a good thing I got the slides up and running then. We did a presentation yesterday, the Database Working Group about the status of mirroring other routing registries and since the key word routing is in here, we thought it might be a good idea to bring this to the routing policy Working Group to get your feedback. We would like your feedback on this. And this begins with a small problem statement. Currently, we mirror several routing registry databases. If you look at the little grey box on the left top RRDB. Imagine it's another routing registry. From there on, we get a stream of their data. Not all data, unfortunately is exported and there is no protocol for it. In many cases, it is definitely not RPSL and there is actually no one that implements the full RPSL RCP exclusively. All different and different to ours. When output changes, obviously our conversion breaks, there is no protocol and at this point, our Whois update is not being updated. Basically meaning we are going out of sync. When we do get the data, we change it to RIPE RPSL format. Very strict RPSL and we adhere to this strict meaning if there are attributes in the originating source that we don't understand we will not import them. They will be dropped F they are in a format that we don't understand they will be dropped and so on. After this they go into the RIPE database and allows to you query is with dash A and S flags we already know by the time they go into the RIPE database we do not have a complete view of this, this is simply a fact of life. Now, if an individual users query it, may not be so bad. Maybe they are looking for some statistics, some general ideas or they will just continue on looking if it doesn't look right. However, ISPs and internet exchanges also use this for operational purposes. They will build their routing policy based on what the RIPE database says and not only for the source of RIPE, they will also do it for some of the mirrored databases by us, effectively treating us as authoritative for data sources we are not authoritative for and that we know full we will we are not complete on, either. Regularly, unfortunately, tickets reach us from users, from internet exchanges, and asking, what is going on? It appears that my IP space is not visible in the UK, from one ISP or another. There was an old route which we mirrored and imported and that there was an updated route which, for some reason, we could not mirror and import. The UK IPS or internet exchange still sees the old route in our database, treats it as authoritative and routes the traffic somewhere it shouldn't go any more. And basically blackholing the entire traffic. This is the operational issues that come from this. So we actually being treated authoritative for data that we weren't authoritative for. On top that have we actually only mirror 7 out of the 40 routing registries so if you wanted to go for the convenience sake go to the RIPE database and say show me a good enough we can't we have one out of six, if you will. Looking at the type of queries that are being done, you can actually see that on the lefthand side, the orange and red chunks of the pie chart are wrong use of this extension, the s flag allows to you query for a very specific source, which is not us. Most of them are still using source that is we no longer mirror. So they get errors back anyway. And there is people that use s RIPE querying the RIPE database so there is no point in using s. For the a usage there is queries that are only ever going to return anything that is in the RIPE database. Maintainers, organisations, these type of things. Leaving 12 percent people who do use it and S doing sensible queries and that is about .4 percent of all queries we get. If you look on the right-hand side you will see the green and blue chunks are IP and AS that is what we are mostly being queried for. It's not personal data, it's not maintainership or anything like that. We get 7 percent domain queries, those are only in the RIPE database so we can disregard those from the pie chart and there is the interesting five percent which is the reason I am standing on this stage. Five percent are route queries. We would like to know from the audience that probably knows most about this, is this you doing queries to us to build your routing policy. And were you aware of the shortcomings of the mirroring of other databases? If you were and you are still doing it do you think it's good enough. If you weren't aware and you are doing it, does this scare you?

So, the way that we see forward, we thank we could possibly do, things to make things better, keep going as it is. We know it's incomplete, it's error-prone, it can be misleading at times, we know we have a limited view and we do get some operational issues from it but there might be value and we would like to hear from you what this value is. We could be authoritative and only be authoritative on the things that we know we are authoritative on, which is only responding to queries for the RIPE database. We know those are correct. Which would mean we would deprecate the a and the s flags allowing you to query further sources because we wouldn't mirror them or we can meet in the middle and say, well we will do a referral [unclear] won't mirror the database but we would know where could you go get the authoritative answer. We could do this as a proxy service or as a web service in front of the database but this would mean that would you get the replies in the format of the remote registry rather as in RIPE RPSL, because let's face it, they are in a different format for a region. You are asking to make oranges into apples and that doesn't always work, this is the way that LACNIC operates their joint Whois service as well. So our questions to you and anybody willing to go to the microphone and say something about that. Do you use the [unclear] or other operational decisions.

AUDIENCE: Yes.

SPEAKER: Did do you so being aware of these [unclear]?

AUDIENCE: No, nobody was telling us.

SPEAKER: Would you still be wanting to do this knowing these limitation

AUDIENCE: Knowing the limitation and keeping in mind that if I have queries that I want to resolve against completely non-RIPE Database, I would prefer and I usually do run the query against the appropriate database.

SPEAKER: That is very prudent of you.

AUDIENCE: If that database is accessible and works well and doesn't create problems, which happens with certain ones, but more and actually, and actually for example, for some time we were using the RIPE database to query for APNIC data because APNIC serve actually was creating some syntax error which was breaking our tools. So, actually, having so actually having the RIPE server sit not guilty front and filtering away some irregularities, is of value. The other use for asking different databases on the RIPE database is, sometimes, sometimes we actually need to run a database resolution against multiple databases, because the references in the distributed IRR are crossing the registry boundaries and, well OK, for that, you need a database server that actually is doing mirroring.

SPEAKER: Wouldn't you need a database server that is able to give you the answer?

AUDIENCE: Yes, you are right, but, well OK, the current way this is done, usually, is by mirroring and I was generalising, which was an error but again, having the database front end that I am querying actually normalising the objects that are returned is definitely a value because, well OK, yes, there are irregularities and, well OK, keeping all the tools in sync with all the irregularities that are around, of course, is much more work and harder to maintain than to rely on a central point of service that actually normalises in the first place and, yes, well OK, information about that the normalization actually removes data. , of course would be valuable and knowing this, the decision about using a certain database for certain queries might be changed.

SPEAKER: From what I understand, you are saying we would want to query multiple databases somehow, anyway, and it is very convenient if somebody else can do the conversion for us.

AUDIENCE: Exactly.

SPEAKER: I appreciate that, that is also exactly the problem statement I am presenting to you, this is what is failing. We have tried very hard to make it not fail but it's making apples into oranges. We can do a best effort and we have been doing on this, but unfortunately, our best effort, because it is being treated as authoritative and correct, is leading to operational issues. So are you sure this is what we want to do?

AUDIENCE: Well, again, the cost again the cost for every one operator to maintain his tools for the idiosyncrasies the broken server of the day, does not look like something that is helping to keep tools in place and working. My experience in using the service is that, well OK, I never I don't remember any error report getting back to me knowing that I may be missing some information is an incentive for me actually to create a little bit more of explicit feedback loop with my customers and I would feel perfectly comfortable if I sent my customer regularly a report that says, well OK, you have your you have the relevant data spread across strange servers; I am trying I am trying to make best sense out of it with the help of the RIPE NCC and here is the query that I am sending to represent your requirements and here is the today's result for this and if you find anything missing there, please investigate. Again, the point is, well, OK, the information that well OK, there may be white spots has to be transmitted. If that is transmitted correctly, things are not really that bad.

SPEAKER: Understood. Is there anybody but Rudiger who is having so much faith in us that they built their routing policies based on the answers of mirrors. Could I see a show of hands?

AUDIENCE: We trust you you.

SPEAKER: Of course you trust us, especially if they are using this, like to add to this.

CHAIR: I have a bit of procedural thing and repeating on what I said yesterday. The way this was presented has come across at least to me a bit too much of hand waving with lacking on details. Upon hearing this I am surprised to hear having issues with people like. The RDB have run service called IRD which is developed against I I would like to know, if it is the case, that they have the for RPSL or perhaps the RIPE database if, this is true and what are the details and if there was a good reason and one or the other should implement the changes have that be added because RPSL

SPEAKER: Answer in one sentence.

CHAIR: APNIC runs the RIPE Database software, with some local modifications. I would be very surprised if there are such modifications that they are not reconcilable. So again provide some data. That is the main thing here.

SPEAKER: I have answers to both of your questions if you are interested. The first one is short no one implements the first RSPL spec [unclear] make us change twice a year at least and as for the numbers I have them, I am happy to discuss them over coffee with you and also mailing list

CHAIR: The mailing list would be far better than over coffee.

Just to close this down. Sorry for keeping you so late, the discussions will have been interesting to all of you or at least most of you. So let's just go to the does anyone have anything to that they would like to add at this point or just everyone desperate for coffee. I was talking to Rob Blokzijl, we have decided to postpone the beginning of the next slot, which is the last plenary slot, to a quarter past 11 so you have a chance to stock up on coffee and probably grab a bite in case the plenary slot runs a little bit late into; you will at least have something to digest. Thank you for coming and see you in Dubai.

(Coffee break).