These are unedited transcripts and may contain errors.

---

The Routing Working Group commenced on the 10th October at 9:00 a.m.:

CHAIR: Good morning. Welcome. This is the routing Working Group session for RIPE 5. I am Joao Damas chairing this session. The one of the two other routing working chairs is Rob Evans sitting here in the front line.

So, I'd like to thank Franz from the RIPE NCC for being the notetaker for this session and that for being the Jabber interface. Thank you very much. Hopefully you have all read the minutes from the previous meeting at the RIPE 58 were circulated sometime ago, and are there any comments on what was reflected there? If not, then they become final. And this is the suggested agenda for today, it's pretty full, but if anyone has any other items that they would like to see discussed, maybe we can squeeze them in. Is there any other thing?

So move then to the first talk.

NICK HILLIARD: I am Nick Hilliard of INEX and I want to have a little chat about IRRToolSet and RPSL. More about IRRToolSet actually and rather less been RPSL. It's actually slightly unfortunate because RPSL is very much associated with the database Working Group which of course is back?to?back with with this session. So we are stuck.

RPSL of course ?? or at least IRRToolSet brings its own problems because we're ?? we really have a bit of a problem with it. It's more about awakening the undead. It's not a very nice piece of software unfortunately. Now, just a bit of a background.

The whole project started out some number of years ago, where there was this grand idea. And the grand idea was really all about documentation and about, you know, creating a central repository or a bunch of central repositories where we would have a specified routing policy written up and, you know, we could somehow use that to arbitrate, you know, with disputes and routing policy or use it to work out problems with what was going on in the Internet, and, you know, some people thought, you know, hey, that's cool, we can use it to automate configuration as well. We'll create glue, we'll write software and all of that.

This was all the routing arbiter project. And it was started in merit. In fact, it started out with RIPE 81 which devolved into RIPE 181 and because this was seen as a pretty good way of describing Internet objects in a standard way ?? this was long before the horrors of XML were unleased on the world. And people figured, well, you know, we can extend RIPE 181, and we'll kind of build client software and server software and the server software is going to, you know, do the parsing of the objects, make sure they are all okay and the clients software will do this funki stuff and that was fine. So the routing arbiter project slit off into two areas. There was the routing arbiter database, RADB, which is still in existence, and there was RA toolset, which was actually fairly shortly moved to diff 7 in ISI in California where other institutions like ICANN and ISOC and things like that hang out, or started anyway.

There was another project sort of going on in RIPE around the same time, called pride, which was the policy based routing implementation and deployment in Europe, it's a bit of a handful, but it ended up actually with some quite useful tools, because this was still in the era where CIDR was you know sort of just being introduced and, you know, we needed you know sort of all sorts of tools to help us with the translation, or at least the transformation from classable routing to classless routing. And RA toolset, at this stage, included a whole bunch of useful stuff, CIDR adviser, PR path, and so forth.

And that was fine, things moved along, these tools were written and they are kind of ?? some of them worked quite well, some of them didn't, RT config was always a bit of a problem in that it didn't work terribly well.

Of course, you know, funding runs out and eventually the RIPE NCC took over the development of the whole RPSL?NG project where people suddenly realised RPSL is really only been v4, we need something to do with multicast and IPv6 as well. And RPSL was also enhanceed to include all sorts of other objects like, sort of peering sets and router sets and filter sets and that sort of thing. Around this time the project was renamed to, to be IRRToolSet because it wasn't really the routing arbiter project any more. It was a little bit more international. RIPE hired a developer, Katy Patricia to fix things up. She did a really good job. But like a lot of these things, it came to a grinding halt because, well the bulk of the work had been done. RT config and lib RPSL and, you know, these sort of programmes, were, had become multi?protocol aware, and there were a couple of other programmes like that were kind of in there and you know the code was beginning to stink a little bit at this stage. The specification had simply become too large. The code was becoming too complicated and very few people understood what was going on in the code. Which sort of led the way into the sort of the teenage years of IRRToolSet. Nobody really understood what was going on. Nobody wanted to hack ?? of course the problem is, we are kind of all network engineers. We are not C plus plus coders. And this was like really, really complicated C plus plus. This wasn't just simple stuff.

And the project was handed over to ISI ?? sorry, not the ISI but the ISC, who had a certain amount of interest in doing something with it, but not really a huge amount, and it kind of eventually just kind of sat in the corner, nobody was terribly interested in it. The RIPE NCC didn't really want it. ISC didn't have any resources to do anything with it. And the result was that it just suffered massive bit rot. C plus plus moved on and nobody was really doing a whole lot with it; it didn't actually even compile particularly on most operating systems. And this was pretty bad really. In fact the only reasonable that it exists was because the people from the open BSD project, or some people who had commit access to the open BSD project had created a bunch the patch sets, and they had maintained it to a certain extent, to the extent that it would actually still compile an open BSD which was really rather useful.

It is, as I said, spaghetti inside. It is just a tangled mess of inheritance and, you know, sort of all sorts of classes. And there is this whole joke in C plus plus, or at least in C, where you compare all of these languages, about shooting your foot off and you know in C you just shoot your foot off but, you know, when you shoot your foot off with C plus plus, you below half the neighbourhood away. It's horrific. There is all sorts of the modules that are complicated. There is, for example, one of the things that really very few people understand is the regular express management. Of course if you are dealing with complicated regular expressions you need to convert them and there is a whole library in there for dealing with conversion from regular expressions to, say, finite state automozone, or at least a non?deterministic finite state automozone and back again. And this is like really, really complicated stuff. Nobody understands this terribly well except people who write regular expression libraries. It's not good.

There is also another problem, and that is the licensing. The licensing is an absolute crock, and there are one or two people from, in fact the Debbieing project who documented the licences and the licences came out to be 70 kilobytes worth of information, because each particular group that had worked on the code had imposed their own separate licensing restrictions and probably the most difficult part to deal with is actually this regular expression to non?deterministic non?automazone code, which is jointly licensed by ISI and IBN and includes an non commercial clause, if there is anybody out there using IRRToolSet for commercial gain, I am sorry you are in breach of licence. You are going to have stop doing it.

So this is a problem. I don't know how easily it can be resolved or if it can be resolved at all, because sure as as well nobody in ISI is going to be terribly interested in this. I am not sure what their current licensing policy is for projects like this. It is very unlikely that IBM has any corporate recollection of ever having dealt with this project. I think actually they might have still own the code from gate D or something like that. It's really not terribly clear.

Getting back to the real world for a moment. There are still some die?hards out there. There are people like me who actually kind of used it to a certain extent. Even though in fact it probably just deserved to rot in its grave. I mean, okay I am kind of dising it here. There are some absolute gems of codes in there. There is smart stuff in there. I kind of look at it and think, wow, that's amazing, and, you know, the project ?? the people who wrote it, in particular, Jengas, they were just like seriously smart guys but unfortunately they left something that was so complicated that it's just completely unmaintainable.

Particularly INEX, that's the size of our primary route server configuration file, it's half a meg, and that's for 30 something clients. It's not actually a huge number. 8,500 lines. I mean, if that scales up, and in particular in larger Internet exchanges where you know it does have to scale up to hundreds of clients, you have to have some means of generating router configurations of this size, cannot maintain them manually. And you need a tool like IRRToolSet.

So, one afternoon, I kind of had a go at it and, you know, like all of these problems, you start off and you sort of peel a bit of paint off here or there, and fairly respectedly it descended into the Texas chain saw massacre, and it was pretty savage after that. I committed quite a lot of damage actually. CIDR adviser of course, very useful in mid?1990s. Not so useful in 2009. That was gone. PR path and PR traceroute from the pride tools: Yeah, I mean PR traceroute was in they arely slightly useful, but in practice probably not particularly. And you see, these tools had just been sort of shunted into the code, and bits of libraries had within sort of dumped in there from all over the Internet. And there was no cohesion. I thought hang that. They are gone. And I killed them.

AOE and ROE, the autonomous system editor and the route object editor. These needed special treatment with the a silver bullet just to make sure they are dead. Actually to be fair, they now compile, if you go back into the commit just before they were removed, they actually ?? one of them, actually the AOE compiles, ROE is completely dead. It was never updated to support multi?protocol RPSL.

There were a bunch of bugs. Hey, bugs happen. I added a couple of features. Read line support in RT config and a new development things like that. Rebuild of the auto config environment. And a few other bits and bobs in RT config.

This is what happened to the code. That's what we killed. And that's about what we kept. The original code base was 112 thousand lines of code. We are now down to about 40,000 of almost incomprehensible data.

And these are the development targets. We are going to FreeBSD, Debbion, Mac OS. Mac OS because a lot of network people ?? ? you can see in this room, everyone is using Mac theses days. And you know whenever people are playing around at home and they want to settle down for a nice evening of messing around with RPSL and IRRToolSet, they'll probably do it on their MAC rather than the sort of Solaris server down in the data centre.

But this is slightly away from the central point, which is that I did an all of lot of damage, and the project kind of just needs to die. It's too complicated. Nobody understands it. We need, if we are to be in any way serious about managing RPSL and turning it into something useful that people can you know develop and general route router configuration, we need to stop pretending that this is a useful code base to work from. Unfortunately, it isn't. Unfortunately for me because I put quite a bit of work into it. Unfortunately for other people like Katy and Jengas, it's simply too complicated.

Okay. On RPSL: This is just a quick graph of the object spread in the RIPE database, and we have INET numbers up here and domains and routes. That looks rather exponential actually, and in fact it if we plot it out on a logarithmic scale, that's more or less a straight line there. This is actually quite interesting. Okay. So I mean we know that nigh net numbs and domains are important because eye net numbs are what people use to register their information in the database and domains are useful for DNS and stuff like that. But route objects and audit numb objects and AS set objects, they are relatively close to each other in terms of scale. And this is actually rather comforting to me, because it means that to a large extent, the IR db is actually a success in its particular niche. Not the way it was originally envisaged. I mean the original grand idea, that like, you know, we'd have the entire Internet and you could press a button and it would push out configurations, and you know everything would be fine, that never happened; and frankly it's not going to happen. But it does, this whole thing does have a very good niche role for filter prefix, or prefix filtering. And AS path filtering and that sort of stuff. In particular, IRRToolSet implemented in a particular way that for inbound prefix filtering, all you need is you need to have a properly managed AS set of your own, which you can do because that's your your control, and you need your third parties to update the route and the Route?6 objects and to make sure that they are consistent and also, to maintain their AS set and autnum objects to a very small extent. And of course this is really useful because this is the sort of thing that you can just do once. And you never really have to do it again particularly, unless your routing policy is changing all the time. Unless you were renumbering from one ASN to another. Unfortunately out boundary fix filtering is pretty awful because RT config looks up third party object. So if I am peering with somebody else, RT configure will look at my autonomous system number object and their autnum object in the database and unless they are fully consistent with with each other, it will do something, you know, slightly broken.

Here is a good indication of how badly broken that particular part of the database is. This is the actual peering relationship database at INEX. We have 40 something members here. There is a couple who aren't in here, because they asked for expolicity opt out. And this is what the IRR database thinks of what's going on here. As you can see, it's a pretty serious problem. The green bits are where the routing policy is consistent. Or consistent, yes, we peer. The red bits are consistent, well, no we don't peer. And the these little exclamation marks in orange and purple or well, one side thinks we peer and the other side thinks we don't really peer so we don't really know what's going on. But you can see that, whoops, it's not so good.

Where does this leave RPSL? It leaves it at a system which has a very important niche function. It's like multicast. Multicast was initially designed to deliver height content, I don't know, sort of high definition TV on demand and all this sort of stuff. We found out that was a broken idea. RPSL in the same way is useful, has a niche, and a lot of people use it out there rather quietly. But it certainly did not meet its original specification.

So there we go. That's all I have to say about it today. It would be useful to discuss RPSL in context of what to do with the actual specification, because the specification is far too complicated. It's a difficult code. It's got some things which are inherently difficult to manage. And if we go back to this graph, if you have a look at the absolute numbers. For things like router sets, I mean there is literally only about maybe eight or ten router sets which have ever been inserted into the RIPE database. And INET routers and you know all of these things are just so far down the scale that it's just ?? they are just hardly used, and sometimes I just wonder if everything below here shouldn't just be thrown into the bin and maybe we'll just remove it from the RPSL?NG specification.

So questions? Does anybody have any comments or opinions that they'd like to express?

AUDIENCE SPEAKER: Hi. This is Shane Kerr from ISC, and I'd mostly just like to say thank you for putting up with the horrors of the code. I have worked with it a bit and it is very difficult to work with. Unfortunately you probably just made it useful enough that it's going to last another ten years. So...

NICK HILLIARD: Probably.

AUDIENCE SPEAKER: Geoff Huston. I am just trying to understand where that slide said, I got something working. And in my language, what I think I heard you say was what I have got working are a bunch of filters that could filter origination?

NICK HILLIARD: Yes.

AUDIENCE SPEAKER: So in my parlance what I heard was basically you can do origination from this set, but not much else seems to work?

NICK HILLIARD: That is ?? yeah, that's about correct. We use it for exchange route servers and in that context, it's really useful. There is never going to be an exact parity between what IXP clients announce to route server and what the IRR database thinks they ought to be nounsing, but it's sufficiently close that we can just sort of say well look, kind of make sure that your filters, or at least that your route objects are up to date. And if you are having problems with a particular prefix, look, check that first.

AUDIENCE SPEAKER: Geoff Huston: Thanks.

CHAIR: Thank you very much.

(Applause)

CHAIR: Next topic was by Ruidger.

RUEDIGER VOLK: I am Ruediger Volk. I have been working with Deutsche Telecom and have been around RIPE for some years more. Other the recent years, I have been focusing and being allowed to essentially look into BGP policies, thinking about security there and building configuration systems for this.

What I want to do is report my personal views from recent small workshop that ISOC had invited four people who are working on similar stuff like me with the idea of outside the specific agendas of the IETF and the various operator groups to have a focus on, well okay, what can we actually do from an operator's point of view to practically improve the information that is passed around for routing purposes. This was a fairly small room and we had a decent number of people from the larger networks. Actually I figured out all of the participants were representing networks that were not only from free continents, but well, okay, I think essentially all the operators were multi?continental. Actually two of the most prominent content providers also had their engineering stuff there with people who are dealing with the routing security stuff.

The thing went a little bit more into identifying requirements and options, and while, okay, we didn't really go after building an action plan, there will be ?? or well, okay, we expect that a common report will be published sometime, but we don't even have a draft at the moment and so the best I can do is present the personal view that I took from it and, some of the conclusions that I made personally I am not making, I am not making very clearly the distinction in the talk what's personal view, what's kind of group statement, because we haven't really worked out an agreed group statement.

Just looking at how the discussions in that workshop helped for providing contributions at this RIPE meeting, I have to say the workshop very definitely was helpful. Though, looking at the discussions and results, there is nothing really spectacular and well okay, only a few small surprises maybe.

For going into more of the details, let me first try to chart a little bit a map of the area. We were interested in practical, we were interested in practical progress which essential means okay in things that happen happen short?term. We did not really go into depth for longer term things, and well okay, the interesting question is: Where is the boundary? And I tend to say, well okay, for getting serious security, we really need security elements in the routing protocols. And doing that is going to take a while. We know that the work on routing security has been already around in the previous Millennium, and well okay, it wasn't only RPSL actually, the RPKI initiating work already started there, and a couple of years ago, there was a rush of discussions about BGP extensions for security, and that died down. And the expectation that suddenly, within six months we get to a conclusion how to do that doesn't look very likely.

So, essentially, short?term practical means things that can be done without changing, adding something to BGP, and well okay, put maybe allowing for very minimum development of additional router software.

Having given that kind of map, let me jump over and here I am staying pretty close to our preliminary notes. I want to go through the high priority items that the group identified, and well okay, this is a sorted list.

The highest ?? the highest importance actually was to ask the question well okay, is the group thinking that well okay RPKI is actually worth something? And well okay, I think it is not really surprising but it is actually valuable information that well okay, all people agreed it is something, RPKI is something that we really ought to pursuit. Now the devil is in the details and we'll have to see what particularly we need to do.

Second item, second priority was that well okay, for the discussion of what are we expecting from the RPKI system? It was considered a very high priority thing that the RPKI system, as such, should provide uniqueness of resources. Of course, with the caveat that during transfers, there will be transient data where things are showing up in multiple places, but this is essentially the answer, or this is essentially the requirement we figured out related to the question: "Do we demand a single router system or not?" Well, okay, we don't really mind how many routes are there, but we think it is the responsibility of the top level entities in the system to assure that there are no conflicts between them. How do we assure this? Okay, well that's their job, but don't get back to us users and tell us, well okay, you are relying parties. You can read the legal small print and figure out for yourself every time whether you believe ARIN or APNIC or the devil.

Next item: And that was a small surprise for me. The question was raised well okay, guys, we have this IPv6 thing coming up, and well okay, we know IPv4 data is a huge lot and a mess. IPv6 still looks pretty nice and small, and I was surprised by the answer that the colleagues sat up and said okay, it should be a high priority to actually clean up the IPv6 thing before it gets big, and well okay, even do this under circumstance where we don't have the nice RPKI ?? if we don't have the nice RPKI system immediately available, try to make sure that we start to operate with good authorisation and allocation data in IPv6 as soon as possible.

Of course, we are concerned about doing the IPv4 thing, but well okay, we know that's going to take sometime.

Then there was ?? and some of the items are from the preliminary notes and I have a little bit of trouble to figure really out what was said there. Well, okay, essentially most of the operators that were present are, at the moment, doing something where they have a database that is local to them and where they essentially track the authentication ?? authentication? Okay, that's interesting. Track resource holders or the sources and the allowed routes for their customers ?? well, okay, as we progress, we need to take care of this and make this better.

A need for a certificate distribution and validation which it is kind of give us the software tools for actually accessing all of the RPKI data locally and make that information directly available for whatever operational use we have.

Next item on the list was, as we progress, we really want to reduce the cost of doing safe business. At the moment, the trade off is very clear: If you want to operate safe, it's really expensive. Well, okay. We are not really sure where on the trait of scale people are operating. We have examples and proofs that, well okay, in some cases people actually have more checks in than we expected, but we also suspect that a lot of things, most of the operators are really on the cheap side of the trade off scale.

The question of what can be done about path validation was felt very important by some of the present parties. Though, well okay, for essentially all of the other items, I think we had ideas how those items can be tackled for the path validation in short?term. We did not see, as far as I remember, any ideas how solutions could be done.

From the other notes, I also see that there are at least two items that were considered very worthwhile, but for whatever reason, didn't make it to the top priorities, and these items are origin validation, which is something I will go into a little bit more specific later.

The hint of, well okay, folks, if you can't prevent things going bad, make use of monitoring services like some of the functionality that's available in RIPE RIS. Okay, use it.

On currently used information, I didn't write down a lot. What I noticed was that quite obviously, the distinction and the distinct roles of the RIR allocation data and assignment data versus routing registry data obviously is getting pretty confusing to some people and well okay, in some regions, maybe more than in others. And there was only me for a party mainly based out of Europe on the from the RIPE region. I still claim that the situation based on the RIPE database, is somewhat to be preferred over what we see in the other regions. I did hear and note that parties from the ARIN region were saying, well okay, we are not getting full support for routing registry, and ARIN, in particular, is actually introducing confusing information without specified semantics into their registry data. I was a little bit surprised there.

Anyway, one of the points that was kind of identified was that well okay, folks there usually are trying to track the assignment to identities of organisations. Well that of course is not really directly related to the autonomous systems and the routing system, and in particular, there were complaints about well okay, it's so dam hard to track the organisations because all the time they are changing names and the organisations are changing and relations between resources and so on. So, well okay, there is not only the problem that the databases, in particular do not really provide the direct relation to the routing system or even any kind of authorisation. But well okay, people are forced to try to track moving targets, which is making things even worse.

So, well okay, let's move on to RPKI.

Well, okay, we felt that over the long time that the routing security work in IETF had taken and the long time that CIDR has working on RPKI, well okay, the operators got lost over that long time and as we are now approaching actual deployment, if we want, we really need to focus on operators' needs and bring them back into the process. What we also very urgently need is to clearly identify the concerns and threats that might actually lead to people really staying out of practical use of the RPKI.

In the collection of people that were there, there seemed to be a pretty ?? okay actually, an ugly picture where, well okay, the actual RIRs plans and policies for doing the RPKI seem to be pretty unclear. I think that's not true for all the regions and it may be just an information flow problem in some cases. But, it may also be really a publicity that there is more publicity work needed.

Well, for getting a little bit more done, well okay, we figured out, we very much need to take close care of the policies that the RIRs will operate their RPKI services under. The uniqueness thing was already mentioned in more detail. And well, okay, the threat question is interesting as at the first take we figured we clearly see that people are afraid that for whatever reason, surprisingly, authorisation for their routes may go away, and we need to take care that this is minimised or completely worked around. This can be done some part by establishing the right policies which needs to be done in the RIRs governing bodies and user fora and there is a need for documented and implementing works around for the remaining cases an we had a very helpful contribution on this from Steve Kent yesterday morning.

One of the things that got lost from the priority list was the origin validation thing, which is something that looks viable as a short?term practical improvement, though it requires small extensions of existing router software, the idea is, well, okay, run a server where you collect all the RPKI data, do the validation and provide a channel to a router so that the authorised pairs of prefixes and origin ASs are made available to the policy engines in the routers. There is a draft for the related server router protocol out there and we know that major router vendors actually have working and very efficiently working implementations of it. The customer base may need to work them a little bit more to actually get this stuff in a usable form onto the product road maps.

Another thing that ?? well, okay, I don't know where it was mentioned ?? well, okay, yes, there was at least a question for, well, okay, what about software tools? And in particular, there was one party that was saying please give me a wichet that I can use as a drop in replacement for my existing RPSL based thing and use RPKI instead. And as far as I can see, the proposal of mapping the RPKI base row ace into the RPSL, as discussed a year ago or even earlier here, actually allows for that pretty nicely.

Other parties were saying well, okay, it would be a really good idea to have open software for whatever commonly used functions are needed for the RPKI, and well, okay, from the large operators point of view, probably the cheap access to the software is less interesting than actually having all the functionality available to all of the community at low cost and easily accessible, because well, okay, the security improvements are most effective if many people can participate.

Since there were large enterprises involved, well, okay, always the question well, okay, how does it work on the business side came up once in a while. Everybody feels that at the moment, routing security, unfortunately, doesn't have a really convincing business case. Other projects, other features usually are considered much more attractive and furthering revenue and margins more. The idea of, well, okay, doing improved security with new tools, new systems in ways that are much more efficient and maybe even cheaper in some cases than we have at the moment might be an argument in some cases.

Unfortunately, overall, well, okay, it's really hard to see a big thrust behind this. And then there is, of course, a question how to plan, how to plan for the next generation of systems and we are in a cycle time of something like five years ahead where, well, okay, we unfortunately can tell we probably will need considerable additional hardware power for driving a long term safety enhanced routing system, but well, okay, we can not really tell what exactly the requirements are.

So, I guess that's all I have. Thanks for your attention, and any questions?

(Applause)

CHAIR: I think there are a couple of questions coming from Jabber.

AUDIENCE SPEAKER: So we have Daniel Karrenberg from RIPE NCC who is in the next room I guess. But it's following.

Thank you very much Ruidger for this report. I apologies for not being present in the room. Let me say that I am very happy about these meetings. In fact, they are organised by an ISOC activity that was created while I was chairing the ISOC board. However, I am somewhat concerned that the RIRs are not present at the table there. In your personal opinion, is that because the ISPs present there don't want the RIRs to be there or could this?

RUEDIGER VOLK: I think it was a really good idea to have a selection of participants for this first meeting. It is quite clear that somewhat different groups should gather together and do similar discussions, and I think opening up and well, okay, maybe going to larger audiences makes sense, but having a small focus group of very like?minded people together, I think was extremely helpful.

AUDIENCE SPEAKER: He has a second question. On the clear requirement by the ISPs present to have the RIRs and IANA responsible for consistency of the member resource registries, the RIRs recognise ?? the RIRs recognise clearly that this is their job, and since the RPKI will be based on the registry information, this is in hand. Please pass on this message when that process continues.
So I guess that was not a question, but a comment.

RUEDIGER VOLK: Thank you.

AUDIENCE SPEAKER: Geoff Huston, APNIC. I have, I think, two comments and possibly a question. But firstly, let me address one of the comments from the prospective of someone in APNIC. This issue about consistency and accuracy of our data across the RIR system is certainly a known problem. The major aspect of this problem has actually been in the allocations that occurred when you and I were both in kindergarten, they come back to that early period of Bs and Cs where the records have passed through many hands to get to where they are today and actually understanding what the live people are and where the resources associated with has proved to be a problem. There were about three or four years ago, up to about 7,000 anomalies that we could identify in our published information and across the system, we have been actively trying to get that down to zero. The good news is that in part of our stats files now, we are pretty much at zero. There are still some small numbers of anomalies, but by and large, this is a recognised problem and we work very, very hard to make sure that we do have accurate data that is unique, rather than clashes that are confusing.

The second comment comes from the work that we have done in APNIC on this RPKI. I think it's useful to understand precisely what it does and what it does not do. What it does do is provide an alternate view of our allocation assignment database. It's the same data as it always was. It is formatted in an X 509 certificate package. You can use it algorithmically different than if it was just as key bits and the fact that it is signed and signable says something quite tight about who APNIC was, the signer, and who the recipient, or the current holder of that resource is, the public key you are signing across. So we hope and trust that this information is useful. But we are not telling you how to use it. That's someone else's job.

Now, the next part of my final, because I have a lot of hats on this one is as co?chair of the dear old CIDR Working Group. We are now three years late. And part of the issue why we are so far behind charter is the amount of useful input to help us get our work done has been astonishingly small and instead of making constructive work, we tend to do nothing for a while while everyone en masses the tender and the fireworks and then every few months we light the spark and watch the configuration of the mailing list to see who gets CRISPed next. I welcome this as a constructive way of getting over that kind of behaviour mode as a co?chair of that group and I would welcome this report and further discussion at the next IETF meeting in Hiroshima. So my question to you ?? I got their finally ?? is are you coming and can we expect this report?

RUEDIGER VOLK: I hope the current economic downturn doesn't convince my management that I should not go.

AUDIENCE SPEAKER: Would this obvious appeal from a co?chair help with this?

RUEDIGER VOLK: It might be very helpful, yes.

AUDIENCE SPEAKER: Ruidger, I am from ISOC. I am the person who invited this group together. I am sorry that the draft is not out. I do appreciate the details you gave me today, and I am looking forward to getting those slides, because maybe I can get the draft a little bit better before I ship it real soon now.

I'd like to give a little clarification on the ARIN comments that you referred to. I think the perspective that I heard was that in ARIN, the belief is that the quality of the data in different database is better than the quality of the data in the IRR. I think it was quite as condemning as the way you phrased it. But let's see how it works out when we get the draft reviewed.

The large enterprises: I actually tried very hard to make this just service providers. Just network operators, and so it wasn't that these were large enterprises, it's that in some large enterprises there are networks big enough that they have network operators and so what was represented here was a network operator that happens to be captive of a corporation rather than one that sells services but the intention of to keep it call network operators.

And the item about losing from the priority list the origination supporting the routers, let's treat that as found now.

RUEDIGER VOLK: Okay. John, again, thanks a lot, and sorry for not mentioning you explicitly. Actually we even have another attendee from Japan around this meeting, but I think this was very helpful and slightly different groups, I think, can contribute in different ways.

CHAIR: Thank you Ruidger. Thank you to everyone who commented. I think we'll hear more from this in the next meeting.

The next talk is Vince Fuller giving us and update on LISP. We have had talks on this earlier as an alternative to IPv6. So...

VINCE FULLER: As you know my name is Vince Fuller, I am employed by Cisco, and I am here to talk about rather than correcting the past, I am talking about a proposal called Lisp that's hopefully going to try to correct the future in terms of fixing something fundamental in the IP architecture.

Before I start, can I have a quick show of hands of who in the room has seen a LISP presentation before?

That's fewer than I thought. Because I was ordered by the co?chairs to not do another LISP tutorial, so I promise that had this would be just an update. So I have three introductory slides. If you want more information about LISP in general and an explanation of what it is I am talking about, go to URL WW dot LISP4.net. There is a lot of information there. The reference will be at the end.

What am I going to talk about it a brief review of the problem statements. So good and bad news about where where he stand and where they think things are going. A very brief review of LISP and the LISP database and new technology that redeveloped to help Mick LISP, implementation and deployment easier, namely something called the LISP map server and LISP mobile node.

What's going on in the testify and the standards world and then talk about the current deployment implementation status as we stand today.

So, to start: What's the problem and what provoked this? Basically, about three years ago there was a workshop sponsored by the IAB in Amsterdam where we looked at the depressing routing and addressing problem in the Internet. And the conclusion was there the routing, scaling the routing and addressing system was perhaps the most important problem facing the Internet as it grows to be larger and more ubiquitous part of the world economy and operations of day?to?day life.

So we need to find a way to scale the Internet and to scale the routing system in particular. There is a reference here to a presentation I did about two and a half years ago at APRICOT that kind of goes more into the problem statement. I recommend looking at that if this is new to you because not only is it define the problem but it also has some description of the analysis that we did to project where we think things are going in the future, and it has a whole bunch of references to earlier work that's been done on concepts of addresses, names and the whole, what the whole point of the separation that you'll hear me talk about between identifier and locator, which is we believe is fundamental to making both the routing system and the numbering system scale.

Another show of hands: Who in the room has seen this graph before or some version of it? Come on this is basically a graph of the Internet routing state going back in time when dinasaurs roamed the the earth back in the 1980s. There is a couple things to note on it. There is a blip here looking at the beginning of 2009, as Geoff Huston will point out, this is actually his data and his graph. That's actually an anomaly in the data collection. The way that BGP feeds changed around the end of last year, so what looked like ?? the information that he was graphing changed. So there is no little spike and decline there. That's an artifact of the data collection.

The other to note that I think are important is that if you look have 01 to 02 there is a flat line on the graph. That was the big Internet bubble melt down when basically all growth on the Internet stopped. The thing that's interesting to note is not that that occurred, but if you look at the far right side of the graph, when we are ostensibly in the middle of a bigger economic melt down, you don't see the same drop in growth and for people that worry about future growth trends, that's a little bit disturbing because if a melt down in just one part of the economy back in 2000 caused everything to stop, but a melt down of the entire world economy is not causing a similar melt?down today, well that means that maybe growth is continuing faster than we thought it would. There is a ?? it does look like there is a slight decline in the slope there at the end. That may be due to the melt down, but the fact that it didn't flatten out completely is kind of interesting.

There is good news and bad about the state of the world. A couple of years ago Geoff did analysis work that suggested that the rate of change in the Internet, in the routing system was actually outstripping the rate of moores law so to speak, for processing and memory to get bigger and faster. More recently analysis suggests things have settled down a bit. Maybe that's not such a big concern. But we don't know whether that's due to the economic slowdown or it's due to the Internet actually getting better and bugs being fixed. There is a lot of uncertainty here. So we believe that there is still a problem to be solved. The trend continues to be up and to the right and the fundamental problem of multihoming on the Internet is still there. It's expensive to do. It imposing a cost on the entire system and it's something that for the Internet to really be a key part of the economy, it has to work right, because if you are going to make your business depended on your connectivity, you need to be able to connect in multiple place to say make it reliable.

LISP, turns out while we were looking at solving the Internet growth problem we found a way to make the multihoming in general easier and more effective and with more options.

Quick review: What is LISP? Basically LISP is an implementation of a locator identifier separation. What that basically means is that we are taking the current address space, the 32?bit or 128 bit numbering space and we are splitting it so that the numbers have two sets of numbers with different meanings. We end up with one set of numbers that we call EIDs, they are assigned to end systems. They basically ?? they are associated with an organisation, they don't change when an organisation changes how it connects to the Internet. The other set of numbers are locaters. They do change, they change based on the top logical connection of how your organisation, how your host connects to the Internet and this separation is key, because the only way we know of to make the routing system scale is to aggregation according to topology. That's what we can do with locaters as long as we can change them as the topology changes. But people don't like the number. What Lisp does is maps between the EIDs that are used by the host and the locaters used by the routing system. I can think of it implementing a two level forwarding routing system where the end systems use a different set of numbers and route information than the core of the network.

We wanted all this to be easily deployable, all that good stuff.

I am going quickly through this. This is a picture of how this works. It shows some devices at the edges called ingress town routers, egress town routers. It shows that when a source hosts at one end with some numbers in green, wants to talk to a destination host on the other side, again EIDs in green, it shows how a mapping is performed, an additional level of encapsulation is done by the ITRs to send it through the provider routing system in the middle, using the locator numbering. Then the ETR on the other side that deencapsulates and sends it to the host using the EID numbering.

If you are interested, I can certainly explain it in detail later or you can look at the tutorial information.

What is this thing that's talked about in the same sentences LISP, known as LIPS ALT? It's a database that defines dynamically which EIDs, which host numbers, which organisational identifiers are currently happened to which locations on the Internet global topology. It's the mechanism that the ITR uses to figure out, given a particular EID, in other words if a host wants to talk from 1001 to 2002, those are ID I. The first pact as to figure out to get from 2002 to the top logical place on the Internet. The ALT is what provides that information. It's an overlay of tunnels, other tunneling mechanisms can be used. ..running over it that's used to distribute just the EID blocks so you can have an alternate topology where you can forward a packet that's destined to and EID for which you have no locator. That packet is forwarded to the appropriate ETR that owns that EID that then response with the locator so that you will packets after that can be sent directly over the network topology.

This is an example of what ALT looks like as originally specified. Basically the purple lines are a bunch of tunnels with BGP running over them. The advertise the EID blocks that they own. That information is aggregated by the intermediate ALT routers and then propagated through. So that when an ITR at one side needs to get to one of these EID destinations, they can toss a request into this alternate topology which will route it across the tunnels. It will get to the ETR and it can send a response with the actual mapping information. That way, once the ITR has the mapping information it knows, all it has to do is to encapsulate with an outer header the locaters and it can send the traffic natively, it doesn't have to use the ALT once it has the locator information stored.

That was a quick review ?? that was the two minute review of how LISP and list ALT works. I recommend looking at the tutorial information.

One of the new things that we have added since the last time I presented on Lisp was the concept of map server. We looked at this mess we had created and got feedback saying we don't want to run BGP. It's really complicateed to administer this stuff. How about you make it easier. What we did was we came up with a level of interaction, that's a theme that you hear about a lot in the LISP world where we have map server. Its responsible for propagate that go prefix into the BGP topology. And then on the other side there is a map resolver which takes a simple request from an ITR and figures out how to get that to the right ETR. The only thing that the ITR and the ETR need to know about it appropriate map resolver and map server respectively. We use the at the moment resolver and server deliberately because it is analogous in many ways to the DNS. Where you look on your host configuration it hasn't resolved that conflict that lists a budge of placing to to get answers. It doesn't have to know about the whole DNS topology. This is a similar way of making things simple. This is the same picture as above except with the map server and map resolvers introduced, there are no purple lines going to the ITR or E TRs because they are not parts ating. The same thing happens. Host wants to send from its EID to a destination EID sends the packet to the ITR. Now the ITR instead of having to look something up in BGP and forward on its topology, it sends a packet off to its configured resolver. The resolver is now talking to BGP. It's the one that forwards into the BGP topology and that goes to a map server where the ETR has registered that prefix and then can forward onto the destination, the ETR and then to the destination host. Again the ETR answers the question back to the ITR. The ITR now has as map cache entry and it can forward traffic.

This is a more detailed example of how this works. First step is that an ETR has a prefix associated with a bunch of hosts at a site. It registers it with with its map server. Again just configured. The map server now prop gates with BGP, that registered information to the rest of the ALT topology, including to all the map resolvers that are out there. Now when the ITR wants to get a mapping from one EID to another, again it just sends the request to the map resolver, the map resolver now forwards it through the BGP topology. It gets to the map server at the other side. Then to the ETR. And then the ETR sends the response back to the ITR. Again, note that the ETR responds directly to the ITR's locator. So the responses don't travel across the ALT and don't go through the server and the resolver. They go directly back from ETR to ITR.

Next new bit of technology we came up with he called the LISP mobile node. We looked at this new thing that we had invented. Map server map resolver and, someone observed that these map servers would be interesting anchor points if you wanted to implement some sort of host level mobility, because basically what you can do is a mobile site, a handset or something, can register with a map server, which then can propagate, aggregate information about all of the mobile devices that are associated with it and that that lookup can be used for another mobile device to find, to do a query to find the locator of the mobile device even if it roams. There are some details about how the caches are maintained, because obviously if you are caching individual /32 or/128s, you have a more complicated cache management issues, when things are moving. But it's basically the same as the basic map server map resolver technique that we developed. The mobile node registers with the its home map server and then the map server will answer on behalf of it so that the map requests don't have to go all the with an I to the mobile node and don't have to be answered by it. It doesn't have to be on full?time.

One thing to note is that LISP encapsulation is used as the mobility encapsulation, so all packets sourced or synced by a mobile device that is using LISP mobile node will have LISP encapsulation.

The mobile node spec is in an individual submission, it has not yet been accepted by the Working Group. It's going to be going into the Working Group at a future time.

This is kind of graphically what happens, again I have eight minutes and I have other things to cover so I am going quickly through this. The important thing to note is that just as with the regular map server/map resolver case the mobile node will register with its map server and since the map server is propagating aggregated information about all the EIDs that include this mobile node's EID, other parts of the LISP network can find that mobile node or can get a locator for that mobile node simply by querying the mapping database using map resolver and LIPS ALT.

The other thing to note here is that while the map request to find the appropriate locator will take, will have additional stretch across the mapping database, the actual data from the mobile node and between mobile nodes travels directly between locaters, so there actually is no additional routing through a home agent or anything of that sort for the data that's being originated or synced by a mobile node. This is kind of important when you talk about ?? when you look at things like streaming video coming from a handset, where you don't want to have to introduce additional delays. If my handset is roaming here from the US to Europe and I want to simulcast this presentation back to people elsewhere, I don't really want to have that traffic have to go all the way back to the US to my home carrier just to be transmitted somewhere else.

I am going to skip this example but it's hard to explain begin the time I have. It basically shows how the mobility works at the data plain when a mobile device moves from one provider to another. We support both make or break where you have multiple addresses on the handset if you have a make?or?break situation, you actually can continue your communication using the mobile device without any loss of data. If you have a break and then make case, then there may be some loss of connectivity in between. But it shows how the map cash entries are updated when two mobile devices are talking to each other.

Again more in the draft that describes mobile node and again on LISP 4.net that has tutorials.

What's happening with LISP in the standards world. It was first invented kind of as a result of that routing address workshop three years ago. It was talked about informally at the San Diego ITF, there was a presentation in March and then starting in Vancouver we started implementation and we started doing testing co?located with the IETF, with updates at the RRG and doing informal BoFs.

At the San Francisco ITF back in March we had a formal BoF for LISP and at the Stockholm IETF back in July, the LISP working group was created and all of the existing individual drafts were incorporated into the Working Group.

There was active discussion on the Working Group mailing list that is not readable on this slide very well. But LISP at IETF.org. If you are interested I encourage you to join the list and look at the archives of the list. There is been quite a bit of discussion, clarifications and actually some good fixes that were pointed out to the specifications.

Where do we stand with respect to implementation? Well the original implementation started about two and a half years ago on the Cisco and XLS software basis, things that run on the NX 7000, we ran it on a rackmount PC so we had a low cost committees platform and we could easily upgrade and work with and ship out test device to say beta sites. There is a Linux code base that underlies it. There is a bunch of interface level stuff that hides that. The implementation does include everything described in this presentation list. LISP ALT as well as tomorrow diagnostic tools for determining whether the mapping database is working. Currently it's all software switched. Its prototype. That will change in the future as this becomes production. It will become a hardware switched implementation in next generation hardware. Hopefully in some current generation hardware if we get the headers right.

There is support for IPv4 and IPv6, not only that you can do arbitrary encapsulation of IPv4 over IPv6 or IPv6 over IPv4. So this is potentially a transition mechanism for getting islands of IPv6 to talk to each other across an IPv4 backbone.

The these function alternatives is implemented, LISP NAT is one of this. Again more descriptions on the website about what inter working is about.

Other coding efforts that we know of. There is an I oh S implementation unway. Officially it's not done yet. Unofficially we actually have completed the first set of coding on it and we are doing some internal testing of interoperatability between IOS and the titanium NOS platform now. We are looking at doing XR implementation and outside of Cisco, there is one ?? at least two implementations that we know of. This thing called open LISP that is a little bit behind the current specs but does implement the basic functionality. It needs updates to correspond with packet changes in the most recent specs. There is another one not listed on here called LISP clicks which I believe is Linux based and has recently this week been confirmed to be interoperate with the system with both IOX and INOX and is coming along nicely.

There may be other efforts out there. I have heard rumours of some other implementations but I am not sure what they are. If anyone knows anything, let me know.

Deployment of this stuff, we have a pilot network that's been in operation for roughly a year?and?a?half, about two years now,. I know that there are people here in this working FR Group and at the RIPE meeting from at least four continents that are participants in our beta network. We have about 30 of these titanium routers deployed out there and again that is the NX OS based software on the titanium.

We have a set of prefixes that are signed for EID space on its pilot network and we are also just kind of as an aside, the LIPS ALT topology, the GRE and BGP between the different devices in the fiddle are actually using addresses out of 240/4, which is space that was reserved for future use, but it's trivial to change the implementation to support it. Some of you May remember we put out a draft about two years ago trying to make that space be usable, but some people said oh you can't do that because it will slow down IPv6 connectivity, you can't do that because it will take forever for you to install base change. So the draft is out there and it's actually as I say, it's about 15 minutes to change compile and deploy that change. So we are using it.

The RLOCs, again the locaters are toll logically assigned. They are using the existing attachment points of the participant sites on the Internet.

This is a quick picture of the pilot network topology as it stands today. It's kind ofclustered into several different areas. There is one area for Europe, North America and there is an area for the A P region where there areality routers and server map resolvers that provide service to the devices that are locate top logically in those regions.

We have implementation of the inter working. That's basically how you transition from a non LISP world to a LISP world. It's operational today. LISP 4.net is actually behind one of these inter working boxes so it's actually on the LISP topology but you can get to it from anywhere on the Internet.

LISP is an open effort. This is not something that Cisco has any IP O on. It's not something that Cisco is promoting. For all the push back we get on telling us how it's not feasible to do it outside of Cisco. There is probably ten times as much coming from inside saying this is a dumb idea. It's going to save the Internet and make us not sell so much expensive memory any more. Imagine having to fight from internal and external. We think it's the right thing to do. We are interested in more implementations, more testers, more designers, more researchers etc. So if you are at all interested in this, please either find me or send e?mail to our mailing list, which is here,. These are the websites. Those are the URLs for where there is more information of all sorts.

This is just a list of the Internet drafts. The ones in green are the core specs and the ones in red are research specs, which are what we thought about and discussed but aren't actually pursuing.

That's it. I hoped I saved a little bit of time there.

(Applause)

CHAIR: Has anyone any questions?

AUDIENCE SPEAKER: One quick question: Tom vest. Have you guys done any work on what you anticipate to be the frequency or scope of the RLOC renumbering events and any thoughts about anything other than the actual number participants in the system that might actually be a determinant of the frequent ski and scope of those things, things that might make them be more or less frequent.

VINCE FULLER: One of the things to note about LISP is basically it doesn't require RLOC renumbering ?? you don't re?number the RLOCs unless you change your connectivity to the Internet, which is something you have to do today anyway. Basically, the RLOC is ?? what it is is basically the point where your CPE routing attaches to your provider and that number is always going to change when you change providers.

AUDIENCE SPEAKER: I am talking about the inter RLOC, basically the inter?domain, the inter working space.

VINCE FULLER: For the inter working space, well, I could go into a really long discussion of how the dam nicks of the current ?? I guess you are asking about the legacy Internet and how much information has to be propagated between the LISP network and the legacy Internet ??

AUDIENCE SPEAKER: We'll talk about it off line.

VINCE FULLER: It's kind of a long discussion we can have about it. I guess that's it.

CHAIR: Thank you very much.

(Applause)

CHAIR: So, as you might remember at the beginning, the agenda had one more item. Rather than keep everyone around here for longer and on doing a poor service to a discussion of this item which I think has raised a lot of interest, we are going to make use of the fact that tomorrow morning there is a slot where ENUM is, doesn't have a recession running against it and we have asked the organisation to kindly let us use this room, starting at 10 a.m., and then we'll take the half hour to discuss the remaining item so we can do it properly. So, if you are interested, please show up here in this room tomorrow at 10 a.m.. and we'll go through it. Thank you very much.

(Applause)