Monday
Monday 27 October 2008
Plenary, Address Policy WG
The plenary session commenced as�follows:
SPEAKER: Good morning, I am chairing this session we are just trying to� we have had a bit of beamer change, bear with us for a moment. (ISP is ISP) looks like we have resolved this. We are going to kick off this morning /A*ES's session with some updates from the Internet regional registry. If I can ask my colleague to come up and give us an update on what is happening in the AfriNIC region.
SPEAKER: Good morning, everybody. Eye name is earnest. I am talking on behalf of my colleague Lillian who was supposed to have come and give but due to last minute minute changes wouldn't be able to make it.
First of all I would like to inform you that we had a major restructuring of the organisation and re/STR*UBGS was three main departments or areas: That was communications area, the finance and administration area and the technical area.
The coms area where we take care of training, events management and web design, where the administrative area we take care of the general day to day admin tasks, human resources and the accounting functionate technical area would be in charge of the running the network and the infrastructure, software and database functions and the intra source management functions.
So this restructuring was started at the beginning of the year and right now are pretty much all these functions are (
Looking at some numbers, after three years of operations we have, right now, a staff of about eleven, we have three communications area, five in the technical area and 4 administrative and financial area.
Membership, we have about 495 members as of September 2008. We have so far had about 78 new members in 2008 so and we are getting the budget for this year we are looking at budget 1.5 million USD. Policy side, one global policy (can't hear)� �
Membership growth from the beginning of 2005 we started off with about 197 members, we inherited from the� and at the end of the second quarter of 2008 we had about 448 members, so the membership is running quite steady and we are quite happy in this regard.
IPv6 same story, we started off with about two IPv6 allocations, at the beginning of 2005 and by mid of 2008 we had about 48, right now it's about 52 IPv6 allocations.
Compared to the other regions of course, these numbers are very low but looking at the overall growth in our region, again I think we are quite happy with the way IPv6 has been taken up.
More numbers; this graph will show you the trend of IPv4 address allocation and assignments. Again, if you look at the graphs in blue from 1993 to 2003, you can see that the growth was not that� there was some growth but not very considerable. As opposed to 2004 and then 2005 and above, the graphs in red when AfriNIC actually started managing and distributing IP addresses in the region, the growth started looking very good. So yes, one can, therefore, conclude that we have had an impact in the, when we started managing the allocation and distribution of numbers in the region compared to the other registries from were doing before we took over.
From 2005 when we became a registry, one of the things we focused on was training and if you can look at the map, actually, the areas in green are those that have been covered and the areas in brown are those that� the areas have in green have had IPv6 training and those are in brown we plan to cover. We have had about 34 training sessions since 2005 and since 2006 we have had been focusing mainly on IPv6. Towards the end of 2008 we are looking at five more session and all of them will be focusing, again, on IPv6. We, of course, also working on improving the training tools, on line training materials. We are constantly revising our training materials and hand outs that we give at our sessions and we are also, of course, setting up virtual testing lab, a virtual lab with IPv6, with six deploy consortium that I will talk about in the next slide. And we plan� therefore our strategy is to cover the whole continent by the end of 2009. It looks quite optimistic and quite certain that we will make it.
We, of course, cooperating and working with our sister organisations in the continent. There is AFTLD, which is Africa top level domains, we provide administration and financial support and there is AFNOG which is equivalent to the MENOG of this region, that is the Africa Network Operators Group and we provide financial support to their meetings which are held every year. Then there is the after can universities' association and the other association for the research and communication networks in Africa. We organise IPv6 and BGP training at many of their calm puss around Africa.
We as I mentioned before, have trained the six deploy consortium, which is a supported by the EC and is composed of 13 organisations, as of three months ago I am not sure what the number is now, AfriNIC, LACNIC, CISCO and others among the organisations that are part of this and their objective is to support IPv6 deployment in developing countries.
Outreach, we have been out there at the very conference and events, South Africa� in 2008� in November, and the from that was I think last week. We have ongoing fellowship programme to support people in the continent that that are waiting to have interest in going to I CTy /SREPBTSD, meetings, and are getting deploy� we have fast training event in cooperation with nigh robe bee. We have about 150 students in this training session.
Our last public policy meeting was was quite successful, that was AfriNIC 8, with a record of about 190 participate pants from 45 different economies. The pie chart over there shows distribution of the� 20 percent (sound is dreadful) and ten percent of the total� we have four policy proposals that were presented and also sometime the board and CEO presented the key parts of� there were elections for board members, our board is composed of primary and alternate members where the primary� the main board member and will function in absence of the primary board member so two alternate board members were elected for the Indian Ocean region and for central Africa.
Some of you may be aware who were planning to have our ninth public policy meeting in Ethiopia but due to last minute change and problems with the local host we had to reschedule this meeting and move it to Mauritius but the dates remain unchanged and everybody is welcome to our ninth public policy meeting that is going to be heard in Mauritius from the 22nd to the 28th of November. The weather there will be lovely at the time so everybody is welcome. So, I will be happy to take any questions if there are any. Thank you.
(Applause)
CHAIR: Any questions for earnest? OK. Thanks very much. Thank you. OK next up we have APNIC and if I can just ask German Valdez to come up and present an update.
Mr.�Valdez: Good morning, my name is German Valdez communications manager of APNIC. In this morning I bring for you some news from APNIC. Coming up in this presentation, RIR meetings, I bring for you some numbers about the allocation activities for APNIC, some services updates and some policy news.
This graph are the� about resource services activities, as you can see even though we are two months away from the end of the year we almost reached the same amount of allocation of/8 we made last year. Also we are going to have a very similar activity for the assignment of system numbers and we have duplicated the total allocation of IPv6 according to the last year so from '94 allocations in 2008 against 552,0007.
We have implemented internal second review system for those last requests IPv4 address request. The� this procedure is about having a second opinion, second review for large request. This works in the following way:
For those requests larger or equal /19, the request must be reviewed by the peer host masters. For those allocations larger or equal /17 resource manager take an opinion on the request and for those requests larger or equal than /15
The senior review team needs to take an opinion on that, the senior team is made of the area managers and director general of APNIC.
Also aim to go keep up better services to our members we are improving our resource management portal which is we call it myAPNIC, version 2 it's a beta version which allows user password authentication in addition to certificate will be required for access to certain functions such as voting and resource certification. We are� this is show one on the portal where you can digital sign the resource that one company has allocated in Asian Pacific, they can sign IPv6 allocation and also to establish . This is aiming also to have a more secure environment in the allocations for the Internet resources in Asia Pacific.
Regarding our activities in the research and development area, we are very busy working in different drafts in the secure inter domain Working Group in the ITF, we are planninging to use this resource certifications, technology to be applied to the host services in myAPNIC. We expect this better version will be released and fully operational before the end of this year. Also we participated in the project day in the life of the Internet. More than 50 telebits from data from our DNS located in Hong Kong Japan and Australia. Also we are working together with RIPE in the test and measurement traffic project. We expect to deploy one of the nodes this year will hopefully be in Hong Kong. This is something that we are really interested to keep going and we are aiming for 15 different nodes across the region.
Other news from the APNIC activities. We are working on business continuity plan, also we are at this moment signing the survey for 2009, members. We are planning to make the survey before the end of the year so get results of our meeting in February 2009. Also we are running a fee structure study with KPMG, taking into effects� service based in APNIC allocation mostly. We are looking for software communication issued by the environmental protection agency. We have launched an IPv6 programme which has all the details on the developments. These IPv6 programme will help to evangelise the activities of IPv6 or APNIC related� we are also in� continuity Mcment system project to be deployed by the first quarter of next year and also we are engaged with successful project that we call information society innovation fund which is togethers with other organisations, we are administering a fund for small grants for innovation projects in Asia Pacific and for projects we receive 148 requests and we pick up eleven projects that be granted with 30,000 US dollars as a support.
Some policy news. APNIC has been very busy in the last month in the policy discussions. This year we have implemented three different policies, the first one is about the reduce or minimal site allocations right now in Asia Pacific, the minimum is /22 and also we change the criteria for allocation of IPv6, this change is basically that those orientation that request have already have IPv4 from APNIC can forget to submit hundred assignment plan. And also we update the NAR operational policy basically we add some IPv6 regulations procedures.
In our last meeting in New Zealand APNIC 26 we have a very busy day in the open policy meeting. We continued the discussion of two previous proposals and we received seven new presented in New Zealand. As a result, there were six policy approved by the community, right now four of them are waiting for APNIC executive endorsement and two for� I like to give you a brief of discussions, the first one was not accepted was returned to the policy list, policy discussion it's a policy about IPv4 address transfers. The intention is to remove some restrictions on registration of IPv4 transfers in Asian Pacific. There are some considerations like the address blocks will be transferred must be /24 or larger, must be in space administered by APNIC and subject to APNIC policy after the transfer.
Some of the policies that actually got consensus is the first one is the proposal 55 which is well known RIPE here as well which is a global policy for the allocation of the remaining IPv4 space. Also we� we reached a consensus we call it user final /8 which is as consequence of the previous proposal. The objective of the proposal 62, which a consensus is to avoid the last /8 be controlled by few organisations. So, the rules that are going to apply to the last /8 to be allocated in the region will be different. Basically, we are currently that each new LIR or current LIR will receive a list single minimum allocation that right now is /22 and also we took research for /16 for potential future technology use.
The proposal 63 which is about reducing the time frame of IPv4 allocations, didn't reach consensus. Right now making allocation considering 12 months, one year period of time. The proposal is made to six months so we have a very controlled allocation so this space we are allocating in a region this, proposal went back to the list. Proposal 66 which is ensuring efficient use of historical IPv4 resources is about we need too� we take the proposal asks for, we take into consideration historical allocation made to the request for additional block so we can have a better control of the usage rate and this proposal is waiting for endorsement on the EC right now.
The final three proposals are related to AS inspection, the first one is proposal to reserve 32 bit AS number block for documentation purposes and the second one is about suggests request to APNIC to adopt as plain format. These two even though they reach a consensus in New Zealand meeting is waiting for detail with issues with ITF processes so both policies are going to be deferred for implementation later next year and the last proposal is about change assignment policy for AS numbers. We add in a new step in the process of the assignment of 32 bits AS number so by July 1st 2009 we will be allocated by default 32 bit AS number and only 16 bits when there is a need demonstrated to do it.
Finally, I would like to extend a warm invitation to the following APNIC meetings especially for the next month which is 27 to be held in Manila Philippines in last week of February. And 28 and 29 in your calenders. Happy to answer any questions. Thank you.
(Applause.)
CHAIR: That is. Any questions for German? I can see APNIC is hogging the calender. We have the president of ARIN ray Pizak who will give us an update on what is happening in the ARIN region.
Mr.�Pizak: Good morning. Passing out a copy of the ARIN report, if you want it in Arabic, please raise your hand, we will give it to you in Arabic. As my custom I do not use Power Point presentation slides, I will just chat through this thing and highlight a few other things that are going on.
First of all we just conducted our latest meeting which was the ARIN 22 meeting, it was in Los Angeles. We discussed a number of policy issues, two of them have been at the last call, one which deals with minimum allocation for the Caribbean and north at lack Lynn islands and the other one regarding a dedicated IPv4 block to facilitate IPv6 deployment. The rest of them are all remanded back to the advisory council and as I say, the advisory council has taken an action to work with authors and maybe merge some of these proposals and others and so forth.
The more significant thing this meeting was that the meeting where we did an enhanced remote participation. As you know most are a webcast and maybe somebody gets up to the microphone with a laptop and says "I got this question from so and so and here it is." Well we changed that slightly for this meeting and our goal is to eventually make the meeting from any location to fully participative one. We did the following things:
First of all we created a window for persons to log into where they could view a realtime transcript of what was being said. The second thing is that we opened up a Java room specifically for the remote participate pants to carry on conversations between each other about what was happening. The third one is that if you have ever been to an ARIN meeting you will know on the stage we have a table and seated at the table are members of the ARIN board of trustees and members of the advisory council. And in this case, one of the Advisory Council members was designated to operate to a virtual microphone so that persons that were remotely registered /KWO pose questions into this room and the person at the (could) at the table would raise his hand and the chair would view this person as being the same as any other microphone queue so people came, their questions came up much quicker that way. And then the last room was, as you know at all the meetings everyone has a show of hands, what do you think of this or that. We created a fourth room which was a hands up room where persons could realtime express their opinions yes or no about proposals.
So, then we did some other things, because there is more going on at an ARIN meeting than just the /PHOL policy meeting. For example if /UFP been to an ARIN meeting you will know throughout the course we are conducting many surveys and the way we enties to you participate in a survey is that we have prize draws at the breaks and so forth and we did the same thing for the remote participate pants, and in fact, we even had a remote participate wane prize. Everyone that participated remeetly will receive a T shirt from the meeting. As we go forward we will be looking at doing other things to increase the feeling of being there, if you will. Our goal is that the only thing you won't be able to remotely is attend a social, and once we figure that out we will market it and be in business for the rest of our life, anyway.
So, but I will say this: It was a success, success from the standpoint that people participated, success that everything seemed to work relatively well. Few glitches here and there but that was to be expected first time out of the box so all and all did well.
Now one of the reasons we want to do this is the fact that, as you know, we have been conducting meetings at a more regular basis in the Caribbean sector of the ARIN region. Beginning in 2010 we will be conducting three meetings a year one in each of three sectors so the meeting that is in the February time frame will always be in the Caribbean, the meeting that is in the June/July time frame will always be in Canada and the meeting that is in the October time frame will always be in the United States, and so the goal is that while we are enhancing the ability for people in the various sectors to come to the� be physically present they will also have the opportunity to remotely participate when they cannot travel to the other sector meetings. So that is the way we will be going forward in 2010.
So, we are kind of we are nailing down three months throughout the year which you will generally be able to find an ARIN meeting. Next year in /TKPEB we will behaving a meeting in bar bait does and in April we will behaving a meeting in San Antonio. The meeting in October we haven't settled on it quite yet, we are still negotiating because we do this with NANOG, have to find some place where NANOG can have enough space, either on the east cost of the US or midwest. Those are things to look forward to as ARIN moves forward to try and broad enparticipation base and get more people involved. You can also see that that is happening as well, if you look at one of the particular proposals that has been discussed for some time now which is a community networks IP allocation, we are getting more and more people from the civil sector, civil society sector to participate in ARIN meetings and by broadening our remote participation we will actually increase that as well and this, in turn, will lead to a greater voter turnout for our elections and greater participation in our governance process. So, if you were at the ARIN meeting you also on the Wednesday /TPHAORPBG bridged between the NANOG meeting and the ARIN meeting, there was a special panel composed of old Internet who discussed what would John have done, discussing the current IP addressing dilemma/crisis, pick your word, and they actually talked about the issues that were involved in the beginning about devising the addressing system and so there were some insights and some old war stories, if you will, from what happened way back when and there were some lessons taken away for going in the future. And that should be available via the archives when we get the meeting minutes posted sometime this week, you should be able to view that on line. Also at this meeting we published the results of our second IPv6 penetration study. ARIN in conjunction with Kate da has done this twice now, first time only in ARIN region, this time we also asked the other regional registries to participate with us and thus get a global view T there were over a thousand Respondents. The results were posted� were presented by [CAIDA] at the meeting and are posted on line, URLs in our pamphlet. So it's very interesting and we will continue probably to do something else more along that line.
I have already mentioned the fact that we have been meeting in the Caribbean. Our lastest meeting informs bar date does and it was a very good meeting. And� excuse me it was in the Bahamas. I spend a lot of time in the Caribbean islands.
The biggest thing in the outreach area, we got two actual thrusts going on one is governance participating with the other registries and with other folks such as ISOC in the Internet governance forum and so forth and we continued to expand our outreach throughout the ARIN region and have gone to many more non traditional place that is would you not expect to see an ARIN presence. We have the ability to conduct several remote participation in several different events at the same time. We have boothings that we set up, information kiosks that allows us to interface with people, we run into� our clients there and actually we gain more people to participate just by become there and talking to them a little bit about what they are missing by not participating. And you see a summary of the summer/fall recap in there.
We just conduct our elections. The polls closed on Friday, and the results will be announced this coming Friday, there were two seats for the board open and five seats for the Advisory Council.
And we have issued a new number policy� a new policy manual because we have just added a few new policy changes to it. Beginning in the 1st of January we are doing four bit ASNs. If you haven't had a chance to see the ARIN report you can go on line. We only do it on line. Don't do it in paper any more and it's an interactive report, if you really want you can download a PDF version of it but it's not as neat as object line. I have already mentioned the next meeting which is in San Antonio in April. This promises to be a good one. If you have never been, there is more than just Davie Crockett and the Alimo. In fact, it has very nice� there is a river walk has many nice restaurants and so forth so if the opportunity aveils itself for to you travel to that meeting, please do so.
That completes my presentation. And if there are any questions?
(Applause)
CHAIR: Thanks very much, Ray. Thank you. OK, that brings us to the last RIR presentation, the last and the best, Ricardo. Give us an update on the LACNIC region.
Mr.�Patter /RA: Hello, good morning. Can I not guarantee this is the best presentation but I will do my best.
I work for the engineering in technical department in LACNIC and we just would like to show some numbers about the membership evolution. This is how different categories of membership we have in our region have been growing in the last, I don't know, nine, eight years. There was a big growing in 2004 and 2007, actually, and this is due to the NIR memberships being incorporated� actually, NIR members being incorporated into LACNIC members so this explanation about this growing, but so if we compare the 2008 to 2007 numbers we can see an important growth, and this green part at the bottom is where most of the memberships are concentrated, the small categories, those organisations which have /24 up to /19 is the great majority of the members in our region.
So about numbers, this is staff. A good exercise would be try to identify each one in these pictures. I tried, but I could not identify everyone. This is how our staff has been growing in the last few years. We are now 19 people working in the office, some of them in partial time but great majority stay in the office for the whole day.
This is the newest one, this is Alexandra works for the communications and Pablo works for engineering desktop support. This graph basically shows how we are dealing with our incoming and outcomings. We try very hard to keep some money so we can guarantee our future, so we could do this� we have been able to do this for the latest year.
We have worked very hard in 2007 to establish our vision and also our project for 2008 and 9. We have been working with some other organisations in our region to help in development and incorporation activities like the FRIDA which is basically a project to help ICT research projects but the big numbers here is that the last four years we were able to give more than one million dollars for projects, the last call ended up in August we received 110 proposals for 18 different countries in the region, which is very good number. We also have worked very closely with government. We had a meeting in the Central America for establishing goals for the government should comply and up to 2010, one of the most important ones is, it was a contribution from LACNIC, is to help in deployment of IPv6, this is the goal for this plan for 2010.
We have worked very hard with the deployment, the support of IPv6 deployment. We also have been working with six deploys, European Commission project. We have been able to conduct more than ten different events or trainings in the region. We have two more under discussions in the region and we have this campaign to try to have other ISPs in our region ready for IPv6 by 1st of January 2011. We have this portal with some information about IPv6, how to deploy it internally in ISPs. We have also this IPv6 matrix, as we call it; the idea is to have some graphics showing the number of IPv6 being allocated compared to the number of IPv6 being routed or announced in the routing table and you can see information by� it's very interesting. Just to show one, we had a training in Haiti and it was very interesting to see that the day before of the training, the IPv6 block was not being announced and they start to be announced at the day of training and how it's regulated. Our last meeting was in Brazil, which was in May. It was a very successful meeting. We had more than 280 participants from three� 30 different countries. We have other events like ccTLD, internet exchange points, security, it was very good meeting. We also had IPv4 depletion panel with local government, discussing the subject. This is more or less about distribution of participants, as expected the great majority was from Brazil, 41 percent. We had some important policies being discussed and this one are the ones that reached consensus, like the distribution of the remaining IPv4 address space, IPv6 PI assignments and we had this one how to use the last IPv4 block. This is 2008/� 04, the idea is to reserve the last part of the /8 to new ISPs joining the market.
We have some news in our policy development process. We introduced the figure of a co chair, it was not in the previous document. We now� we also have this expedite process, the idea is to have means to create a policy proposal, even if it is not discussing the policy forum. It's like emergency policy process.
We also had some regional meetings. This one in Cura�ao in, July. It was very good attended, 70 participants from 17 countries in the region. We had peering and internet exchange point tutorials, IPv6 policy proposals, and discussions so it was very good. We also had a meeting in� the idea is to listen to the community how they think LACNIC should do this outreach activities and listen to some proposals for the IGF, which was also very good. We had more than 100 participants, it was very successful, we had some results from this meeting in our web page.
Some news in the engineering department: We are working in new provisional system, to use EPP to allow ISP to send information to our internal database. We are working on a business certificate authority, as the other IRS we are working in the research certification project and we should have a new network in San Paulo where our main service is located.
And last, we would like to you invite you all to our next meeting 25 29 May 2009 in Panama City, it's a very nigh place to visit and also the opportunity to be in LACNIC meeting. And that is all. Thank you. If you have any questions, I will be happy to answer them.
(Applause)
CHAIR: Thanks very much. Panama City. Wow. If I can ask my boss to coming up here and give us a presentation from the Member Resource Organisation. That is, Axel.
My name is Paul Wilson I am chair of the NRO. Of course I am Axel and Paul can't come, he revets that very much and sends his regards and asks me to present this quickly. So what is the NRO, you might have heard this before or you mightn't. It's the number resource organisation. Basically, it's meant as a vehicle for cooperation of slightly more cooperation of the RARs, as you know we do cooperate quite closely, go to each other's meetings, track what is going on in the other regions and try to get some cohesion into place, maintain some cohesion.
But also, it's meant as a vehicle for presentation where the RIRs can speak with one voice, basically.
A long time ago we formed the NRO to� with three different reasons: One was to protect the� unallocated number resource pool, seeing that we get our resource from ICANN and that is all well but in case something could go wrong at that time, we would have something ready to maintain this. That has become less important by now.
Promoting protect the bottom up policy development process that is talking about it, promoting it, doing education, talking to journalists and to governments, talking about this. This is bottom up industry self regulation, the same in all the RIRs regions and under the banner of the NRO we can nicely talk about that globally. And finally top act as a focal point for community into the RIR system so you wouldn't have to go to the different, talk to the NRO and we will do the trick as well.
We have formerlily established the ASO within ICANN with an MoU we signed in 2004. Basically the number resource organisation has offered to ICANN to take over the function of the address supporting organisation, we have a number council, the number council acts as address council within ICANN. That works quite well for quite number of years already.
The office holders within the NRO and the office are rotating, so the current chair is Paul Wilson, secretary is ideal and I am the treasurer for this year and then by the end of the year this rotates again, I become secretary and Raoul will be treasurer.
The cost of primarily the ICANN contribution but also some ancillary costs of NRO travel and the like and hosting, retreats and similar things we divide among the RIRs and that is based on an ancient and not quite so complicated formula that takes into account Revenue from registry services and the resources that we have allocated in any given year and it so happens that we for this year, pay 37 percent of it, roughly.
As I said, this is mainly the cost of the ICANN contribution that we share amongst ourselves. We have now formally or semi formally exchanged letters with ICANN last year confirming, that yes, we do like ICANN and the way they work for us and yes we commit to making this /KUPB� contribution without any other obligation to us, and while we have paid 800,000� 823,000 dollars in 2008, for 2008.
We do regularly go to ICANN meetings. Also under the umbrella of the NRO. It has become quite a nice tradition already to consult with the GAC, [GAC] is governmental advisory committee within ICANN, with governmental representatives from around the world. It's a nice opportunity for us to talk to all of them that are there but also to people that are not directly from within the RIPE NCC region, for instance. It's quite good. We also had, in February, quite some focus point on IPv6, we talked also to different groups within the ICANN field there, to the large Advisory Council, work ship on IPv6 transition, for registries, for same registries and we also ended the ccTLC members' meeting there. Next week, we will have an ICANN meeting in Cairo. There are currently no formal activities planned, some of us will go anyway, things might happen on the spot and also just good activity to maintain again cohesion there.
And for the first ICANN meeting next year we have a request from the GAC to present there again, this time they are just too busy to look at us. What we have /TKORPBGS this was quite a big activity all the RIRs together. The OC D did the big ministerial meeting in /SO*UL on the future of the at any time economy. So we basically blended together with all our friends from the technical community, the Internet technical community and we have a list of names there. Basically, supporting that meeting, also going to to a meeting just before the ministerial itself to talk about what we are doing, what we think should be happening there and this whole thing was quite a big success and I am quite pleased to say. We got also quite a bit of exposure there to the media and the like. As the NRO we did a press pre lease basically urging everybody on to /TK*UF 6 and invest interest. Governance forum outcome of the� some of the Internet society, we have had two of those and they proved quite OK. Next one will be happening at the end of the year. There is a group that is called the multi stakeholder advisory group, the MAG, that is several times per year meeting in Geneva and we have managed to get two of our crew on to that and they have been reappointed or� they are doing a very good job there. As I said, the next meeting is in December and I am thinking that is about six weeks from now, the year is nearly over.
We go there as the NRO, we have a bit of a booth display material, we take part in planning of workshops and the plenary sessions there. It looks fairly benign, so far. So we will go there and are happy to say also� no, I shouldn't say that yet, I will say that later 6789
Communications: Right. We did as a joint NRO activity a brochure basically detailing as an outflow of the enhanced cooperation also in R cyst idea what we have been doing as in cooperating with stakeholders outside our traditional communities.
Number of meetings that we go to ICANN meetings, hider bad, ministerial, ITU Africa and Asia, we went there under the leadership of AfriNIC and APNIC respectively. Within the NRO we have several groups that look at number of things, for instance engineering and number of things that we do together as RIRs there. And also happy to report that our various boards, members from the various RIR boards have started a now nearly tradition of getting together informally to just, /AOEFR beer or coffee just to talk and exchange their views on various things. I think that is an important thing to do. Also, we are looking forward to have regular formal tell conferences with a set agenda of the board members to look at� and there is a number of topics� to look at things of urgent and immediate interest of awful the RIRs together.
(All of) and I think that is that. Paul says thank you, and if there are any questions, I am happy to take them.
(Applause)
CHAIR: Thank you very much, Paul. Thanks Axel he will. OK. That brings us to the last presentation of this session for this morning's session, if I can ask Barbara rose man to come up and give us an update from IANA. Thanks Barbara.
Barbara: High, I am the general manager for IANA, and if any of you were at the recent ARIN meeting, this is going to look very familiar.
Briefly, I am going to cover IPv4, what is left in the IANA pool; some XML work we are doing on our reg stress /STRAOERBGS some updates we are doing to the multicast registries and an AS numbers update.
As you can see here, what is left. We have 35 reserved for protocol, 182 that have been allocated and that gives us 39 free. The rate of consumption has been somewhat slower this year, primarily due to agreements that the RIRs made amongst themselves for when to come back and ask for additional address space. We don't know if that is going to noon next year, not the agreements but whether the rate of consumption will be similar to this year or whether it will increase.
IANA has been doing a lot of work on turning its registries into XML format. This is to enable people to use them in a more creative and fluid way. For the IPv4 address space registry you can go and look at, we have XMLised this one and the AS numbers registry, as well and we did a couple of updates when we did the XML format for the ASN registry and made a couple of errors and people in the community were very, very helpful in helping us correct that and get the right data in there, so thank you.
Multicast for developing an XML format for the v4 and v6 registries, we are working with the I ITF M /PWOEPBD Working Group and you can go and look at this draft, it's approaching publication and among other things, it clarifies the requirements for eligibility for getting multicast addresses. This is still something that is determined by expert review but up until now, the experts have often had to ask for clarification from us or from the working groups and so we have decided to document as much of that as possible.
With the AS numbers, we worked with the NRO up to date the action number registry to reflect the authoritative Whois server for each AS number. One block of 16 bit AS numbers has been allocated since the global policy was ratified by the ICANN board. And we� we expect to have an update for the AS number registries to use AS plain notation for 32 bit AS numbers as per the draft that is listed there.
You may have noticed that the put out a notice requiring DNSSEC signing for the root. We encourage everybody to look at this. There is several comments that have been posted, responses to the NOI, we think it's all very worthwhile to review. Kim Davies will be presenting further on this during the DNS Working Group this week. And that URL is is a good one to go to to actually see the announcement.
And that is it. Thank you.
(Applause)
CHAIR: Thanks very much, Barbara. ICANN has their meeting in Cairo next week back to back with this one. We wish awe successful meeting. This brings us to the end of the presentations for this session. We are actually quite quick, this time around, so there is a very long coffee break for you all to discuss amongst yourselves. If I can ask you to be back in this room for the next session at 11�o'clock. Thank you very much. That is.
(Coffee break)
The plenary session resumed as�follows:
CHAIR: Hi I am looking for Steinar for the next presentation. Good morning, this is the RIPE 57 plenary agenda track, we have three presentations scheduled for this slot, in fact we had had to make an agenda change because of illness of one speaker, so originally we were planning to have this slot mostly focusing on IPv6 presentations and that is actually going to change a little bit. The first presentation will be the automatic configuration generation and data dictions from Michael shields from Google. After that normally scheduled, schedule, and that will be the study of IPv6 into the main traffic in the Internet and after that traffic categorisation and AS peering presentation just like as in the schedule: Let's start.
SPEAKER: Good morning everyone. This talk is about automated income configuration and how you get there. That is problem that every has its� they have had and they have had had to deal with and it's a problem I think every large network does have or will have. I think most people understand that it's important in keeping things correct to go through and generate your configurations from a database but the problem is you have already built your network and it's hard to understand how you might get there and I have tried a couple of different ways to do that and these are some lessons that we have learned from that experience.
So this is the traditional way that you start with a small network, I mean I think that in a lot of us have done this and maybe this is still the day to day operations at some networks, you just go ahead and off plan and buy equipment, set up power and space, install the equipment, set up all the connects, you config the routers, just log into them and set stuff up make sure it works, have someone else double check, you might some failure modes and there you go, you are done, everything done your network is is a little bit larger than it was before. So we have done that, you know, lots and lots of times, I mean you know you start to wonder, you know, everything almost goes okay very simple, you are very comfortable. What could go problem: You have two routers which are on a single behind it are some servers of your co low customers and those are set up with� set up, this is your standard for config consist co , as simple as you get, VRP for one address and put in the address you have assigned set priority, /TWOUPB 20, set up the same IVP address, cut and pace as router everything is good. So no problem. Here is your config for the first router. You have substituted in those variables. You cut and paste that /TPO*R the second router. And there are power the point problems but the point is you have mistakenly given the same IP address to both interfaces it, seems like a simple missable you are not likely to make, when you have run audits against I have found dozen and dozens of problems, it's possible to could this about one percent of the time if you have a lot of interface that is adds up. It seems simple but humans are not good at catching this. I mean, even if you have someone check your work the second time it's something that is not likely to be noticed because people expect things to be regular our brains look for pattern. It's not something that humans are good at so the first thing do you that is obvious you start going through and say oh, I am going to write something and look at all addresses on my network and makes sure I don't have the same address assigned to the two interfaces and that works for a while and simple things. These are the errors you have: Some of these are insidious because you won't notice them or only during failures. Good examples are VRP problems where they don't actually form a correct VRP fit pair only when one goes down you notice some of your behind it Oregon away. BGB meshes result in block holing� that is something that is just very, veryees to automate and something a good hanging fruit to start with. You add more procedures and end up doing, you know, old bell system A TT style, everyone has to sign off on the form and check this box and make sure it's all an audited, it /KUPBTD work, it's good to get people to look at things, even going through and it's not the right approach, it's very difficult to solve problems that way. You can solve most of them but there will still ablow lying that you will never get it to go away. The only way do this is going /TKPW* through engine rate complete configuration, not just do an audit and make� whether it is but to go through in put in a database first and generate configuration based on that and determine whether it is the one you intended not just some that might have been valid.
It's necessary to do this if you want to have a large network. A truly large network F you don't have this problem yet it's because your network isn't large and it's a good problem to solve now before you do have it because it is a really� it's really a problem which is� it will make your life a lot worse and you will enjoy your job less once it gets to the size you have to deal with this and correct networks scale better, fewer outages better up time and it's a advantage to have this correct.
So this is the core problem: How do you get there? I mean it's easy to say we could have started from the beginning and done this but we didn't, we already built the network and now we have to go through and clean it up and make sure it's correct going forward. How do you get there, what is the first step? So the first step is the policy, not suppose� don't touch the router until it's in the database. So the first thing to you do go and record on the database, not afterwards as a clean up afterwards, and not as the final check off of putting in the as built con figures but the very first thing you do buffer touch the router is you record what you are going to do, your intentions are for configuring this interface. And once you have done that you have a database of what everything is supposed to be and as a side effect it just falls out of this, that you can go through and query that and whenever you need to know information about your network. You don't have to script con figures or log into every router or look at your BGP tables to find out where things are. You can look at database and find where you intend them to be on automated basis, tools do it, all the interim tools you have go:go and associate with that. Here is where you start. Because you don't have the database, the database is not� the first thing you do is create somewhere to store the data, do scripts one time only, all the configurations from your routers and they go and populate the database and once you have that you can flip it around, imagine it flipping around. It now points downwards you need to config the data from the /TKA*EURBs so now you have something which is generated from the database rather than having to be inferred from the active state of the running network. One the open questions there is you can't go� you can't start generating the encounter con figures because than approach won't work, I have tried and you can do it with very simple things such as customer CPE or something that is extremely edge facing but because are so complex it's not a attractable approach so I found the best way to start with slicing one sort of configuration error, something basic like� something even like management, you know, management of routers, making sure they have all the ISP communities, start with that database and slice across the entire network rather than vertically.
So, here are reasons that� here is an example of audit that you will have where you see what you actually have on the left and what database expects you to have on the right and this is an example of a previous error and thousand would have been caught. There are several reasons you will see it works once you start automated section. Something was wrong with your scraper and the data in the database is incorrect because you didn't correctly infer this data from your network. You have been having that problem all along now you can fix it either by correcting your bug or by going through and just manually fixing the errors in the database. The second one are actual config errors you have made a mistake and go out on the router and fix it and now your router will be better for having done that. And the third one is deliberately unusual configurations, things are non standard for a reason or might be because of oversight. Only human can distinguish between those two cases, can know whether it's something that should be fixed on the router and your documentation and /HR*EUGSed as either a one off ad hoc non standard or a new sort the standard ways variant of the mainstream configuration. It's not enough to generate your con figures, you need to check you have done it right something else people try is they will say oh operate this router turn up wizard it will generate to configs and then you can something to cut and paste and you serve the� safety error, but you need to go back and check, machines need to go back and check not humans because humans are not good at auditing at determining everything is lined up. This is something computers are good at it's a little more work to get it working, not just in correctness but also in the time you spend but also in just your enjoyment of your job, you should be able to think at a higher level and not think oh, are these two IP addresses the same or different, I need to check box number 17 to check something verified that. That is something a machine should do. Here is an example, this checks are the same as in the database. The help /SEUS here is a literal..., it's not something which is in the� it's not something which is just for the slide it's part of the audit. The ellipsis is an obiter I built matches anything at the same or greater level. This /KPWOES through the config, there is a...before and after that, it goes down, skips everything down, until it finds area zero and checks to see that the contents that have, there are no ellipsis within it so it has to exactly match are exactly what I generated out of the database and if anything is incorrect it will give you a [diff] as you saw several slides ago with the red and green on the left and right highlighting what is wrong.
This has been a very powerful tool, very useful, this is something that you know you can run it continuously run it from Kron, do whatever procedures you have for determining things are wrong and you can go through and can fix it and you can� you can know that everything is correct. And then whenever you need to know, for example, you know, what interfaces have this address or, you know, et�cetera, et�cetera, you get a direct /THRAOEUPB database because verified what is in the database is the same as what is in the network.
So, once you have all that, let's suppose you want to make some change to the network, that is what really pays off, suppose you want to do something like convert from O SP to cyst cyst it has their names, all the other datas, similarly you have a table of interfaces that has their addresses or customer numbers, any that you need to have. You can go and add existing data to that, use that new column to it and there you are, you have somewhere to keep that data already even before you have configured it on the router and you change your generator to say I am going to start generate as is configs and it goes and does it and now you have something which will immediately say, oh the config on the router the old is different than I expected to be which now contains is is statements and it will tell you exactly what to add and all that roll out is done just by taking what it's generated and putting it in there and there are no differences because you have made them exactly the same. Any time an audit fails you need to go back and look at it and as a human decide whether the audit is failing because you generated it in a way that you don't know and whether because the router is in a way you don't want. Both of them will have come up and it's important to have that human reconciled. So that is example of how you can make a high level change to the network. You can work at the level of the whole network at once just by changing the generator. Is now a function of the data that you have in the database so by changeing that function you can change all the configurations for entire network at one.
The last thing to deal with you need to worry about how to deal with the one offs because there always be things that are non standard and because they truly are ad hoc because it's not something you want top standardise as a variant we have this one weird thing. The best way to standardise that with an abstraction layer where you create a jail for it UAE treat it basically as a co low customer even if it is yourself and you say I am going to standard config where I have some arbitrary method for putting things behind these routers e isolate and be standard themselves and behind it is completely ad hoc a and I am not� physical be small and we /SWROPBT these problems, it will be something you can individually look at and look at two or three router configs and even maybe something as large as your internal behind it but it won't be something that your backbone audits need to deal with and you won't get used to see your backbone audits fail, you want to get used to seeing everything green and lined up.
So what tools do you need for this? You need a configuration collector, rancid is a good start, it has limitations does everything we want. Doesn't scale well beyond a few hundred routers. There are variesious tricks. You need some configuration already collected, audit against them. You need the database. There are no good open source tools that I know for generateing this and every network is different. You will need to build yourself because you will need to customise it for your network. Everyone's configurations are very different and it's no way it's going to be same. It's a lot easier in the last few years to create database backed configuration. Most things are based on� you can you can see /SKWRAPBG go, ruby� you can use whatever tools that you want whatever you are comfortable with it's something that we have a lot of open source things you can network with. You need to config generator that goes with the database. That is part of your templating and you need comparison engine. It can be as simple as a diff just running a diff against it and looking at what is present and presenting them ideally in two column view. Here is how those interact. The database, the routers on the left you know are extracted by the configuration generator and put into some local files and that /RAO* /THOEUS as your as built configs. The database on the right creates what this /T* thinks the configuration should be and there is a comparison engine that goes through and determines what is different, tells you what should be changed in order make one the same as the other.
So that is the summary. The idea is to around an audit. Anything you do on a day to day basis, your bread and butter standard configs or you need to be correct in order for your business to keep running needs to be something that is generate odd out of the database, otherwise you can't be sure it's correct. It it needs to be verified by tools. The way to get there start by fixing one class of problems at a time, the IGP /SPHERB a good /PHRAEUGS to start because it is insidious to have it wrong and boring check, it's something you can fix network wide and start moving on from there. I� communes making sure all your external interfaces have acelse on them, make sure they are good to start and give you immediate pay off. Need to continuously compare, not just create a wizard regenerate the configs and diff them as in this slide. This is probably the single best summary of what you want the state of it to be. You continuously go through and continuously regenerate the configs and compare them and you have to go through and look at the results and determine whether you are going to change the database or the routerment and finally make jails to isolate non standardness, instead of having these areas you know are not going to pass the audit, you have them behind this jail router, that is standard and what is behind it ask not audited and everything lines up and isolated. No matter what you do behind continue it's not going to affect the actual routing policy on your backbone so it's not just� it's not just for the sake of having the audits passed, also for security for correctness, it's for creating that isolation layer and knowing nothing you have done is going to affect the core of your network.
If you don't have these problems, evenly few dozen routers. You can look at them, you might have them occasionally, might not be worth building. If you do it's worth building it as early as as possible. I have had to deal with in networks very large and it's more painful the larger they are and especially the more complicated they are and different sorts of configurations they are. It's better to start as early as possible, simple configurations you can slice across the entire network. You can only get there incrementally, can't start router by router, I have tried it it's a long uphill road to get there. The best way to do is /T* is slice across and solve problem. This is something machines are good for and will help us w computers are very good at generating things. Humans are not good at comparing things. This is something where it's best to have computers do the job that computers are best suited for. Questions? Anyone?
CHAIR: No. Randy?
Randy Bush: IIJ this. Stuff has been done by MCI level 3, NTT vario etc. for a decade. How much is Google actually done and implemented and look other Google things are your tools available and so on and so forth, although Rancid of course is public.
SPEAKER: These are good questions. I am not claiming that it's breaking any new ground here. This is something that, you know, as I said all networks have had this problem, some have solved it more successfully than others. Vario is particularly good at it. I mean the hard part is getting there and the hard part is getting there from a network is already less automated than it should have been, so one advantage that Google has is we have a lot of good infrastructure to build on and a lot of continuous rebuilding the network so there is tools that we have that would not be productivity open sourced, it would be nice but it would be difficult to do so because of the Google infrastructure that they rely on. If you don't have that behind it then it's not something that is going to run on your infrastructure at all. If you can't plug it into a big table at the back there is no open source substitute for that at the moment and it would be nice if there were, it would be nice if everyone had that but I can't get open sourced. So I think that there is a need for better tools, there is a need for things that are more scaleable. I would like to talk to people interested in doing that because I think that is worthwhile effort and I think everyone including Google could benefit. Taking our tools and exporting them is not good but I am trying to show in this what the lessons we have learned from this are and what would be productive. In the same way we have exported� that has been� I know a lot of people yahoo and others are using that, a relatively clusters and that has been something helpful, we have described the technique and without� even if the tools themselves are not exportable it's something that other people are able to profit from the techniques. Anyone else?
CHAIR: More questions? No. OK. Thank you very much, Michael.
(Applause)
CHAIR: The next presentation is study of IPv6 into the main traffic in the Internet by Scott Johnson.
SPEAKER: Good morning. For for those of you that I haven't met which I think is many of you, I am with ARBOR Networks, this is my first RIPE, very excited to be here and very interested (A R B O R) and seeing all the sessions, my colleagues Dana and Craig who participated in this work, so I hope you will come up and introduce yourself after the talk or after the session and I would love to meet some of you.
So this presentation is covering some research we did this summer, studying one year's worth of traffic of IPv6 traffic across a broad swath of the Internet.
So first of all just talk about the goals and background. Most of this is well known to all of you. I will discuss our methodology, how we collected our measurements, then I will present the results we found and have some discussion about some of the limitations and some of the feature work.
So our goal with this work was to provide a global and longitudinal perspective on Internet IPv6 traffic. This is part of a project being conducted to provide a global approximate percent /PERGtive on all Internet traffic. For those of you familiar with us we sell network analysis and detection gear which does both flow based analysis and depacket inspection and many providers around the world who have deployed this against their peering edge primarily also against customer edged traffic have agreed to share anonymised traffic data with us which we then collect and analyse for work such as this and also make available back to those who are reporting it so the value of reporting the data is you get access to all of the anonymised data as well, this covers all geographic regions of the globe, everything from major tier one providers, tier 2, MSOs, content providers, higher education the whole spectrum, leveraging over 2000 network routers that we are monitoring.
The key insights we hope to get out of this study which I expect you will see more of, are better insights into what growth we are seeing and different traffic for application and services and information about the pervasiveness of unwanted traffic, although that is not what I am going to be talking abouted to but something hopefully you can look forward to.
So the data set we do have today is from physical 100 ISPs, have agreed to share anonymised data, tier one, tier two, etc.. sub cateregorisation the predominant geographic region. So the data covers a one year period, covers traffic specifically in this study in and out of the network edge so specifically inter domain traffic between ASNs, data was measured in five minute increments and then aggregated together over the course of the year and again, this is largely based on IP flow measurements for the peering edge, most of our traffic is not coming via /TK*P peck inspection. We have is a global footprint, it's anonymised, of the geographic distribution of the data sources, we do have 65 ISPs in the Americas, 27 across EMEA and 6 Asia Pacific, we have only /HR*EUPBLGD visibility into /AEUGS inter domain traffic and we would love to have increased feasibility there, if any involved talk to me. All told we exceeded by the end of the study five terabits of inter domain traffic, we believe that is the largest measurement of it's kind regarding IPv6.
The context for the study as many of you know we are facing imminent exhaustion of IPv4 space from IANA within the next year or two and then the regional registrars will have course be exhausted at some point not too long thereafter. IPv6 of course solves this problem providing many orders of magnitude more address space and there has started to be some government pressure to make the transition such as past summer's deadline for management and budget for their networks to be IPv6 ready, not that they are using it fully in production but it is at least ready if required and other things like China's next generation Internet initiative.
So the questions we were asking: How much IPv6 traffic is actually on the Internet? There have been various indirect estimates published, ASNs with IPv6 BGP announce, roughly 3 percent, number of Internet 2 sites passing IPv6 grade, about one percent, the Alex /SKPWHRA top 500 websites down to .4 percent and IPv6 DNS queries as a percentage of IPv4 DNS load down to.2 percent and some of this work has been presented here at past RIPE session. What we are going to show today is /TP* we measure IPv6 as raw percentage of all Internet traffic that we see the number is even lower, according to our mesh usualments about 0.0 O2 percent of all Internet traffic being IPv6 traffic so I think we have a lot of work to do.
What was our methodology, how did we conduct these measurements. First of all we have been looking at inter domain IPv6 traffic. Also, we have looked at including native IPv6 traffic, however this requires routers in support net flow vs. 9 or its compatible protocols. And we have looked at multiple forms of IPv6 traffic tunnelled over IPv4 including IPv4 protocol 41 as well Terrido traffic, some limitations which I will discuss later.
So this was our total measurement of all of the traffic, this includes IPv4 and IPv6 traffic over the course of the year broken down by region, so you can see some healthy growth and again, peeking up at almost terabits of total traffic so we believe that is very large study, very longitudinal.
Here is the total IPv6 traffic. If I apply this graph in the same axis as the /SPRAOEF you wouldn't see anything so we have changed the scale a bit. We are now peaking at about 150 megabits as opposed to five terabits of IPv6 traffic. If you look at the median amount of traffic in the fist and last quarter of the year there is about a 30 percent increase so that is good news, /O though again the total aggregate rate is fairly low at about 150 megabits in aggregate total.
The more interesting measurement is looking at IPv6 as a fraction of the overall Internet track and if we do this we see that we are seeing between .0 O2 and .003 percent average. It is growing, it is growing over the course of the year but as you can see, from the percentages here it's growing at about the same rate as IPv4 traffic or if you look at the rod numbers perhaps slightly slower than IPv4 traffic taken overall. So that is little bit concerning, we had hoped to see not expected, mind you but hoped to see the percentage growing over time indicating that there was some migration happening, so based on this data as far as we can tell there is no large scale migration or even very small scale migration to IPv6 other than a very small segment of the population.
So we did release a tech report of this data back in August and there was an immediate impact, as you can see we saw a nice message from hurricane electric tunnel broker and the day the report came out the tunnel request doubled, it was shoved lived but we thought that was interesting. (Short lived). So I have talked a bit about our methodologies and I am sure some of you have thought objectives why our measurements are completely wrong and why we ought to be out of our minds. First of all, yes, we are probably not monitoring your network or if we are, we are including the data with a lot of other people's data so it's entirely possible that this traffic doesn't represent what you have seen from your particular Internet perspective. There are a couple of easy answers to that. First of all I hope you will sign up for thissed to today. However, I think there is some claim to make that five terabits of inter domain traffic is at least somewhat representative of what is going on in the Internet as a whole. It certainly is is a very large data celt so I would hesitate to dismiss it entirely.
We do fully admit there is a north American and European bias to the study and again please see step A above. We would love to have more providers signed up with this and providing additional data so we can make better measurements and have is a better understanding of what is going on in the Internet as whole. In this study in particular we did focus on inter domain traffic. We didn't study intra domain traffic, we have less instrumentation there and also partly because although we do expect IPv6 traffic is perhaps higher inside domains, we are primarily interested in what we see going between domains because if it's not talking to the rest of the Internet by IPv6 they be it's hard to say that it's fully deployed.
And again, our data set is primarily flow based so there may be IPv6 traffic that we are missing because it's not represented in the flow, there are no limitations with some of the flow reporting, software out there based on what router� the routers support different IOS versions and so forth we would like to include more DPI measurements in our future work and tied with the intra domain study.
Some additional objection you may have, we are under counting native IPv6 traffic, I will tell you this for shower, we are certainly under counting, again this is because monitoring IPv6 requires the use of NetFlow v9 and many networks have not deployed this. I think this under scores the difficulty in fully operationalising IPv6, even if you are forwarding IPv6 traffic and you have full IPv6 routing, DNS etc., I don't think you can call it fully operational unless you also have the rest of the measurement infrastructure and the other IPv6 network infrastructure in place, the same as do you with IPv4, so if you can forward it that is great but you also need to have this ability to what this traffic looks like and unfortunately, either for the need to upgrade or lack of software support in the network infrastructure itself we don't have full visibility today into native IPv6 traffic. We are also under counting Teredo traffic. This is because the known Teredo report report is used as control port, the traffic� data traffic itself will use ephemeral ports, with flow based measurements we won't be able to track that, that will require packet inspection, however I can tell /TU of the almost 100 deployment in the data set only two saw a consistent level of Teredo control traffic and only 12 overall saw any Teredo control traffic so I think it's safe to that on the vast majority of these networks we are not seeing any /HOR he had day traffic or at least not very much of T why are we seeing so little IPv6 traffic? So again going back to our findings there was some growth in IPv6 traffic but it is pretty stagnant when you compare it to overall Internet traffic. It's very little percentage wise. Very interested in answering why that is. You guys were /R* probably in a better position to tell us why than we are to tell you but some thoughts we have, one is money, certainly always a big factor; there are increased costs to roll this out to deploy it, to troubleshoot, all of that and it doesn't actually generate any immediate Revenue at this point. It's also a chicken and egg problem. There are no users clamouring for IPv6ed to, most users probably don't even know what it is and there is no IPv6 content that people can't get over the existing network infrastructure so there is no motivation from users to do it. If there is no motivation from users then there is no motivation for the providers to supply and /T* and� again it goes in a circle. We have a chicken and egg problem that we need to break ourselves out of. And lastly related to the previous point IPv4 is working well so I mess with it.
So again, I hope you found this interesting. We do believe this was the largest measurement study to date and we think we have a lot of work to do still to get IPv6 out there and fully operationalised. Thank you very much for listening and I would be happy take any of your questions.
AUDIENCE: I have some other numbers on inter domain IPv6 traffic. It's in the order of 600 megabits /PERP second and rate five in the last half year or something coming from hundred megabit per second in April. So your numbers seems quite low.
SPEAKER: Well, as I said there are other measurements out there. I couldn't quite understand all of what you said. I wasn't sure where you were getting the numbers from that you quoted.
AUDIENCE: So I operate the internet exchange in Amsterdam, the Netherlands with tens of providers exchange IPv6 traffic so we measure native IPv6 traffic using S flow on the exchange and we measure the order of five to 600 megabits per second at the moment and it grew from about hundred megabits per second half a year /AFPLGT I will show that Thursday in the IPv6 Working Group.
SPEAKER: I see. Thank you. Just to address that specifically, this also came up at NANOG a few weeks ago so we aren't monitoring the exchange of course so some of that traffic is certainly traffic that we are missing.
AUDIENCE: It's a public web page, you can easily see it.
SPEAKER: I understand. From what I understand a lot of that traffic is private news peering between providers at the exchange, so, you know, you could argue a little bit as to whether or not would count that as inter domain traffic. I suppose in some way it is but it wasn't primary the type of traffic we were seeking to measure.
AUDIENCE: Martin leafy. Let's deal with that last part before I ask my question. Over half of that traffic is heading somewhere else as opposed to just between peers so it should be measured and the other question which is a repeat from the NANOG talk is, you are not measuring anything on our networks so there is a large amount of missing data and the numbers that come out of AMZEC's are a good example of what is really happening 234 other places so they just don't match your numbers, there is a lot missing from this. But the question I want to ask is, again, go back� well, your last slide, you make a comment in there that the financial� yes, so, you know, why� you is there anything in your collection of data that substantiates that statement or is that just random statement out of.
SPEAKER: Again I think we are look to go you guys to understand that better. This is our understanding from talking to some of our customers and why they haven't made it a priority to roll all this out. , you know, we are not a network provider, we work with network providers so this is basically just what we have heard from some of our customers but you know there are lots of perspectives out there and certainly you guys can help us understand this better.
AUDIENCE: That is into the quantitative statement in any way.
SPEAKER: No, more it was intended to be.
AUDIENCE: I am not sure if we joined your programme yet but we can tell you it's like about 90 percent of our IPv6 traffic is used net peering. So it would be� can you maybe in the next talk make a more specific split on port numbers so we can actually see how much is used and how much is real traffic.
SPEAKER: That is an excellent question. Unfortunately it ties into the fact it's very good to get good visibility into IPv6 today because so few few have deployed V 209 get that visibility but absolutely there is a lot more we need to do here and that would be a very good next step. Thank you.
AUDIENCE: And no problem ever. I have one remark regarding the Teredo thing; one should point out that traffic between Teredo clients and service is basically only handshaking and� machines so you will not see very much traffic going through from Teredo so Teredo will only be used� and given that most amount of Teredo traffic today is peer to peer by this, this will not show up either on the or on the service. So this is sort of something� the other thing is that I am a bit unhappy with packet of number on the first slide, 0.000, because you acknowledge yourself that you are not seeing the v6 traffic since tunnel traffic is really something big providers are moving away from very fast so if� but in the backbone networks have� 6 to 6 deployment there is hardly� since you are acknowledging the fact that the methodology has problem, problem on the first slide there is zero v6 traffic is something that I think doing a disservice to the work of all the people that make v6 happen.
SPEAKER: Thank you. Those are both excellent points. I think the one thing I would say to that is, you know, as ARBOR Networks we are primarily concerned with the traffic we can measure and if can I not measure the IPv6 traffic then I don't think you can claim it's fully operationalised because I have no visibility to what is happening there at the peering edge and again this is something that needs to be worked on. I do fully recognise we are missing a lot of traffic here, we would love to include it in our study in the future. If I give you a couple of orders of magnitude of the traffic that we are missing it's still a very small number compared to the overall IPv4 traffic.
AUDIENCE: It's definitely less than v6 but whether you are talking about something like 0.5 percent which is the number of on our peering edge or 0000 something percent, and that is quite serious.
SPEAKER: Thank you.
AUDIENCE: From NetNod. IPv6 Working Group on Thursday I think� (can't hear)� and I kind of agree to your relations between v6 traffic I also have the question your numbers because I see a lot more v6 traffic permeating single ISPs� �
SPEAKER: Can I ask is that native or tunnelled that you see?
AUDIENCE: Well the termination of 64 tunnels is more into the v6 network than you see in total.
SPEAKER: OK.
AUDIENCE: I should have one question to follow up to that. Do you know the relation between your� data coming from Europe and the US or North America?
SPEAKER: I don't have that data here, we could calculate it.
AUDIENCE: Because I was expecting to have way more USA than� �
SPEAKER: Yes. Again we have data from almost hundred specific ISPs, obviously there is many more providers in the Internet than that so please, share your data with us and we will include it.
AUDIENCE: We are currently building generic platform for measurements out of our DNS data as we issue it and the DNS Working Group meeting, you will see a presentation by Stefan and you actually, as far as France and DNS are concerned, we have already found rather 4 percent of public servers em /EUSs or web servers who are already IPv6; I mean, those are data, those are not traffic, so we may really change people's mind whether we present 0.00 O2 percent or perhaps we are not playing with figures but I think that assumptions, previous assumption are very, very important to highlight before giving figures, otherwise everybody will be misled.
SPEAKER: I am sorry, you said 4 percent is available, IPv6 capable?
AUDIENCE: Yes.
SPEAKER: Yes. So it's a question of capacity versus what is actually being used I think and both are very interesting questions.
AUDIENCE: Did you just say, if I heard you correctly that your issue with v6 is whether it's production, that it's measured and then the comment that you followed up with was that you wanted to make sure that you were measuring it such that could you generate a better measure of production traffic, because you are not measuring everything, the study is not complete? Because if complete and if does not contain both from a time point of view or from a collection point point of view enough information so, instead of defining it from you want more information in order to further substantiate the study I think you are in a different position, I think the study is inconclusive and incomplete, off bay percentage and because you don't have the extra data points, withdrawing it would be perfectly OK by me.
SPEAKER: So just to be clear, our claim is not that is complete accounting of IPv6 traffic in the Internet, what it is is is a measurement of IPv6 traffic across 100 providers in Internet which I think is is a fairly large sample and I wouldn't say that the lack of measurement invalidates the study but I would say we believe measurement is an important component of deploying any network protocol operationally, you need to have visibility in order to understand its behaviour and impact on your network and be able to manage it so I think visibility is important and shouldn't be ignored.
AUDIENCE: I am not sure I caught this number, you say that you don't know how much traffic you get because you suspect� do have you a number for how many ISPs actually do support� traffic.
SPEAKER: I don't have it I am afraid, could I get the number for how many are exporting NetFlow V 5 as opposed to 9 but even some giving us 9 wouldn't support IPv6 reporting in the NetFlow v9 so without a detailed accounting of the routers and the study which we simply don't have I wouldn't be able to answer that question.
AUDIENCE: So you don't know how much� (inaudible).
CHAIR: Any more questions? No. OK. Thank you very much, Scott. Then we are going to move on to the next presentation, traffic categorisation by Thomas Knoll. Where is Thomas?
Thomas Knoll: I think we can start. And I still try to make it in time for the break. First I want to welcome you for my short presentation about traffic categorisation and inter AS peering. It's an introduction, it's a new concept that is aiming for generally available doors grained class of service in the Internet without guarantees.
Short outline of my talk: First motivation for the concept, of course, followed by the proposed improvements and to cut it down to the focus of the concept in order to make sure what is addressed and what is not addressed. That is the third point address issues within the concept following by the BGP signalling part. Why it should and shouldn't be used in the future. The definition of the new BGP attributes, followed by some remarks in the summary.
So first to the motivation. Coming from the Internet we do have best effort packet transport in IP networks which are however locally augmented within ASs through locally applied traffic separation and prioritised forwarding, mostly associated across the multi layer ingress classifications, that is the marking of my neighbouring AS is normally ignored and redone in the ingress node of my AS. Should quality islands exist in our Internet, peer with best effort strategy and ununcoordinated which might not even be globally known. I can't tell which provider distinguishes how many classes in his network.
The other point, there are complex approaches available which do target guaranteed this parameter in mutual basis so the picture shows that our current Internet does have some ASs with certain classes on certain layers and transit ASs which normally are not known which kind of classification is used internally and the interesting point is the BE peering, no matter which class that is used on either side.
So that is why coming to the improvements in the concept. First, provide the knowledge about the available traffic separations in the AS and the applied markings for them. That is, the concept includes crass layer mapping of those separations and signals across domains that information consistently. By that, it makes adoption to the marking available in the transit ASs, however without any guarantees. It is expected to improve the inter AS packet forwarding greatly and consists out of two parts, it's a twofold approach; free to join for operators and can smoothly, well, evolve in the Internet. That is the first part, the global class or the global signalling of the available class set together with the cross layer markings for them, that is the trancetive attribute to make sure that information gets through consistently and the second part is to local class at signalling, paired with limitations for those classes which is done in two separate attributes which are of non transitive types because the information carried is only important for the local peering point.
The lower part I think is the key part of the whole thing: Traffic separation is the key. That is QOS, I have mentioned it in the slides from time to time, in this approach simply refers to the primitive traffic separation into several classes which experience differently prioritised forwarding behaviour in the relaying nodes. Enqueuing in separate queues is aspired, not more or less.
The focus now of the concept makes a distinction between three parts in the AS level QS based forwarding that will be targeted, the QS base routing that might be targeted, not right now and the QS based tunneling which is targeted. To the three parts just some simple slides. The C O S based forwarding, the past election is still done in the traditional way, no changes, but within the path apply the QS per hop treatment. First separate enqueuing. The most important points how many queues, is there a one by one mapping or whether several classes are mapped into one queue, it's an operator choice.
The second part, the scheduling: How are those queues served, round robin, fair queuing, class per queuing, whatever, that is important part in the forwarding behaviour. And last but not least packet dropping strategy, all three together actually make up for the overall experience per hop forwarding behaviour, that is what I mean with QS based her hop treatment in the forwarding case. Yes, well, the picture now changes that the QS based forwarding mainly on the outgoing interface of the boarder routers is now transferred to scheduling and dropping kind of fashion.
The second part is the cost based routing which is not targeted right now, the QS based routing is targeting the past selection. If I do have a /STKR RB ability to leach IP prefix on several routes I can make my decision based on QS available along the paths. So the first sub point would be the best path selection, extended by CoS support to either use those paths which do signalled across the ASs before the others which don't, might be one condition or how many classes are supported might be a condition. As I said it's not the current focus of the concept but might evolve in the future. The other half is multipath traffic assignment. It's possible to have multipath concepts in the future where the peering is not just based on the single path selection but have multi paths to the same prefix, in order to have the path selection in the routing as well. If that is supported the multipath support is given, I could do the multipath distinction based on the QS. As I said, best path selection modification is, well, tough target, and not really aimed for at the moment and the multipath is far in the future, I would say.
What does it mean? I would interconnect AS 3 and 1 on separate transit provider networks but the Red Cross just signals that this case is currently not looked at but not precluded.
The third thing CoS based tunneling, not really tunneling in that kind of natural sense. Tradition or CoS based path selection, and the tunnelled forwarding, so my customer traffic at the peering point gets tunnelled into either tunnels within the AS or in the peering point, first within the AS, E LSPs with priority marking issy involving or already deployed. I can set up separate virtual channels and in order to separate my customer traffic in separate tunnels within my AS. Such tunnelled forwarding is strongly recommended and at operator's choice, of course. At the peering point, tunneling is is a bit difficult; there is work going on with inter AS LSPs, so you have set up across ASs, I think it's certainly not done right now but might be in the future, well closer future. So if I do have inter AS tunnels I would have prefer to have e LSPs in order to have� but I could also go to the layer of 2 markings to have internet exchange point the Internet priority bit side. Have the same kind of exchange but transfer the kind of marking within the Ethernet as well, separate V lance but I think that is difficult to perform, I could also have different peerings between the ASs in separate networks, I was told that it's� I think it's far too awkward to have separate peerings for the concept of separating the traffic I would say the layer two marking is the way to go.
What would that have in the consequence? First I have a tunnel transport within my AS, separating the customer traffic but within the tunnel to have a transparent transport from the customer type of view and to have to CoS based forwarding possibly L2 marking at the peering point. That is focused on in the concept.
So, the address issues: First the cross layer of QOS mapping. On the first table several network types and they are supported QS classes or core groups of QS. These layer 3 markings and QS classes are available and most layer 2 network technology will support such a distinction but the number of classes that are used and they are encoding is often free choice of the operators and not necessarily known outside. The internal policy propagation for such a set up, the classes and encodings is often done or can be done with the BGP policy propagation function for internal BGP so that is why I came up with the idea why not to extend it with
The next point increased usage of tunneling mechanisms and will come up and will be strongly enforced and might lead to BGP free cores just to have signalled time slots, whatever to, cross the core, no BGP available there. That is where course layer mapping comes into place, if I have the marking and the mapping up to the point where BGP is available and have a BGP free core I just swap down my class to the lower layer, get through the BGP core and then go up again with the higher layers so the cross layer mapping is is a vital thing to introduce here.
If I do have tunnels, with different kind of classes on each tunnel, I regard it as layer one class differentiation.
Just an example how such mapping could be done: The DSCP of, 6 bit field is somehow mapped on to 6 built on� but I think that is not a mandatory kind of approach. It could be done in other ways as well. The same as with DSCP from the layer 3 on to layer 2, V LAN use priority bits or to interchanges it within here, so if I do have a class separation in layer 3 and have is a peering point on the Internet I just swap it down to the Internet point / FPT if my next kind of peering label supports the inter AS LSPs I worked it over to the ESLP marking. I want to have a consistent marking concept across all ASs included in the path. That is what is aimed for, the consistent classification and based forwarding behaviour on all layers for the transit traffic.
So what I end up is such a set up, several classes on several layers in each AS. The AS in the middle is here used as a transit provider, also having several classes and several layers but you see a distinction; the internal class set and the external class set. That is for confidentiality. I don't want to disclose my internal set up to everybody in the world but still want to take part in the QS based forward forwarding behaviour so I make mapping in the between my internal set up and globally announced one. As long as those mappings are consistently made, nobody will even realise that internally, a fine more fine concept is used compared to more coarse in the transit case. I used EBGP signalling at peering point in order to get those information required across. The last bit that is addressed, the class overload prevention.
If I do support traffic separation and enqueuing in separate queues, priority queues, it somehow tempts users to put every traffic in highest priority. In order to mitigate that I set limits on those traffic classes and also kind of punishment concept that will be applied to excess traffic. We will see that in the following slides.
First, why did I use BGP? BGP of course is is a de facto peering� it's globally accepted and available. Well designed, such well designed protocol allows for those extensions easily. BGP exchanges reachability information and allows to tag that information with certain route attributes. So those attributes are now used in order to, at the QS concept signalling and marking, on though those advertised routes. As a side effect, it also ensures that the IP prefix is just signalled once, not twice, once for normal route willing and once for QS, so if the combined signalling route information plus� I get consistent kind of signalling across all ASs. The other case is by not BGP signalling, well, BGP is vital to have a stable kind of working scheme, it uses slow update times, dampened updates and the concept of failure confinement within routing areas and maybe con federations if applied. So what is there to avoid? Avoid any fast changing information to be conveyed in the up date messages. I reckon hourly or daily or even slower changes are acceptable but not faster changes.
BGP could also be avoided if there are accepted standards available that already make clear to all the participants which information is to be used, so I don't need it to signal any longer, but for such class concepts in their mappings there are no standards available at the moment that are globally accepted. The other thing to avoid BGP signalling would be if the introduce concept would create huge increase in the number of update messages or in the size of those, both is not the case with the current concept. That is why I go for BGP signalling, that is for e BGP signalling and I do that in the update messages which are roughly sketched here. I don't expect to go into detail here but following the green marker is the withdrawn route section of such update message, on the lower part the actual IP prefixes that are announced as reachable, and the one section that is of most interest to me is the path attribute section, the kind of information take on the up dates. Those attributes are available in several kinds, the one I am focusing on is the extended community attribute which is an optional path attribute.
Getting to the definition. There are three attributes in all, the first one is to QS marking attribute. It's an extended community of transitive type, has a following structure: Extended communities and channel are eight bit containers with the 8 or 16 bit in the beginning and followed by the remaining for the attribute. So the tribunal and tribute is here defined with the 7 bite structure, I don't want to go into each bit here but have a coarse view on� cross view on T remarking ignore and aggregate flag, get back to me if you want the details. QOS set number, technology type is the one field I want to address right now. If I want to make sure which marking is done in the separate networking technology I first have to state which technology is now addressed and followed by the next field which marking is now applied within the technology but there are two marking fields, 16 bit for the marking O and 15 for marking A, that is the marking oh flag is from the original IP prefix originating AS. This field is set by the IP prefix originating AS and it must not be changed a bit in the relaying nodes. So that information from the originating AS gets through globally without any change. But in order to have to local adoption to that marking for the applied QS within the relaying ASs, I have got QS marking A field and each participate pant along the chain can say which local marking is apride for the globally announced marking, so the change of local adoption can be set up using those attributes.
The process count is just there in order to realise how much nodes along the forwarding chain are using the attribute and how many with not.
The O field is 60 bit field as I said before. These that is to be exchanged within ASs, inter domain exchanges, in a format that is defined in RFC 3140 and that is in 16 bit structure. That is why I used the 16 bit O field mainly to the DSCP for standard track BGP in the first part followed by several zeros and the most important thing the bit 14 which distinguishes whether it's single or group, AF groups aren't normally marked with 14 set to one.
What are the kind of properties of that marking attribute: It's optional transitive, it gets through even ASs which don't know about or support the tribute. It has concept of link together attributes, the QS number will be discussed later, that is now. I can introduce several of those attributes in an update message and if I want to have, say, three classes distinguished on two layers, I actually use six attributes to make that clear. One pair per class and in order say which of those six are pairs, I just use the same QS set number with local scope no the up date message in order to pair the attributes.
The technology type as I mentioned before was quite hard to find. There is no consistent list enumeration list for network technologies available so I spoke to several people and got the advice set up your own, five or ten technologies, you will need in the peering points, so I did that.
Processing count has already been mentioned.
The next attribute is the QS capability attribute. That is mainly seen below in the structure, a really simple extend community with just a few bits in the C U /SOG flag field. What are those flags? First of course, signalling that BE /S P supported, that defaults to one of course. Then the next flag signals that E F will be distinguished. The next one, AF, at least one out of the possible maybe 12 AF markings is supported. And the last one, the lower effort approach but if that is supported below best effort, it's also signalled with the L D flag.
Possible classes that are now as class set to be announced could be BE and LE or the BE E AF or all four together. It's just signalling with the simple bits which classes are supported at the peering point.
The second attribute to that concept to the second part of the concept is the signalling of the token� that is if I do support several classes at the peering point I want to set limits for those classes in order to prevent overload situation. So each PHP ID code can be associated with token bucket set as well as with two flags, that is all neighbours which are now supporting this concept will see which separations are there and which kind of percentage of benefit can be used for EF, AF, BE, whatever. So variable length attribute signals the token bucket parameters for those classes and the DR flag says that the excess traffic is just dropped or remarked. (Whether). I just put up the common markings for the BE, EF, LE and the AF groups with the ones at the point 14 flag.
Parameter properties: It's a smooth integration because it's locally used at AS peering points and nodes who ignore such signalling will not harm the normal operation of the network and just not taking part in the QS concept.
The binary signalling is really low processing power so introduction of more processing load in the interfaces can not be argued.
The token bucket parameters is clear, understandable and fair kind of signalling how I treat excess traffic and the other bit that is not mentioned before on the other slides was whether the token packet parameters are just applied for the prefixes below and the up date messages or to all prefixes announced.
General remarks coming to the end. I will point out that distinction between direct peering and transit peering. The main advantage could be in the first one, to avoid the multi layer classification. Just rely on the markings coming from the neighbour.
Define the general technology type enumeration is done within the path. The layer one priority with the separate paths and the QS routing might be available in the future for� especially in the case that the cross layer mapping can be applied to optical and radio networks in order to kind of extend the QS concept on those kind of networks as well.
The usage of such information has already been kind of thought of for the PCE calculations, could be based on such a cross layer mapping but I think that is up to the PCE people to talk about that.
Last point: The high need for consistent class of service concept could evolve through that signalling in the concept. The class set definition and class mapping I just put up the slides in order to see the options that are available. Both listed in four kind of levels, I think best class set definition would be standard and everybody keeps /O to that but I think it's unlikely and not available right now. That is why I go to the second point, have the free choice of classes but tell them what you choose.
The point there /#3* and 4 I think it's just too primitive and I legal it out. The same with class mapping, the best thing would be a fixed standard which says which mapping in one layer should be using which mapping in the other layer. Such a fixed standard would make my concepts redundant but it's not there and that is why I go to the free choice and the signalling of it.
Two last remarks: The first one is IANA. Some of those attributes have already been assigned IANA type numbers and a bit secluded was the clash coming up in those numbers. The zero number was given to the QS marking attribute up to October 16th but extended community types have to make sure that within this numbering there can be a distinction between eight bit and 16 bit type and that is defined each higher layer of 16 bit value is not allowed to be reused as 8 bit regular type which has been done. (8) so now this zero assignment has been removed and I am expecting to see 04 for the QS marking attribute because CO 1 and 2 and 3 are used as high bites. 4 is next available so I assume will be the next and accordingly, the currently assigned will certainly go to 44 since 4 and 44 relates to each other.
The second Quaga, we are currently implementing the concept has no support for extended communities but no regular type communities are checked. It always assumes 16 bit type are used. That is why I just wanted to make you aware of that, the regular types not to be implemented in into the QS routing suite and currently encoding for AS 4 is actually not IANA listed. But now. The modified Quaga source will be available for free.
Summary: The the proposed approach enables a general QS based forwarding which allows for informed marking and possibly routing decisions. It is optimised for ease of deployment and aims for consistent and vitally adopted� approximation. The confidential option has already been addressed with internal and external separated QS concepts and it doesn't preclude any available more complex, more sophisticated QS guarantee concepts but should be available as global base for QS in the Internet. So my vision is to get to the point that we have a two or maybe up to four class traffic separation Internet, globally available and open to everyone. If you do show interest in that concept, simply e mail to me, go to the Routing Working Group in RIPE or to the IDR and express your support, your concerns, whatever, there.
Thank you very much. Any questions? (Applause)
AUDIENCE: My name is Deutsche Telecom, thank you for very interesting presentation, I agree that we need to discuss more the QS in the Internet, we at Deutsche Telecom have tried something far more similar, simply /RELising I have run tests with� even that is very complicated and� � so what do you think about your very complex situation proposal here, what is the chance to realise time frame of the next five years?
SPEAKER: Well, the adoption of such a concept is not really likely on those links which are broadly available and cheaply to be bought. In kind of peerings between Europe and America, etc., it's unlikely to see any kind of such a QS based concept because over provisioning is easily be done. I would expect to have more kind of support for such concepts in the dearer peerings, some parts of Asia or Africa where the current load on the links increases and one reluctant buy new capacity just to make up for better quality so those links I think it's unlikely to use QS separations and I think too complex is that concept, well indeed not really, I think marking on just IP layer is the first step but getting a concept running across several years incorporated tunnel technologies is vital. That is why I think that concept should be applied to dealings and to use the markings across the layer should be quite sensible to do having envisioned that the tunnel concept will evolved quite quickly and globally.
CHAIR: Thank you. Any more questions? No. OK, that brings us then to the end of the morning session and I guess it's lunchtime. Thank you.
(Lunch break)
The session continued after lunch.
End to end
CHAIR: Ladies and gentlemen, please be seated. We are about to start. I hope you had ample opportunity to taste the excellent local food that we are serving here and I'd like to welcome you to this first session this afternoon.
In other words, welcome back, my friends, to the show that never ends, the RIPE show.
We have three talks and we will have, I am just told we will have a long coffee break because one of the talks is expected to be an extremely talk and the discussion following it is expected to be extremely short.
So, without further ado, I'd like to turn it over to Robert who is going to give us an interesting talk and he has assured me it's not going to be a sales talk.
SPEAKER: Hello, my name is Robert hash you can, I am part of the routing development group in Juniper networks for the last two years. I was asked to give some background. Before two years, I was working ten years in CISCO systems in IOS and XR. My background is from the routing protocols.
I know it's always a challenge to talk after lunch and I am the first one after lunch.
So,ed to, the topic of the presentation is 50ms end to end service restoration. In fact, I would like to say that this is the first English public talk on this topic. But it's nothing really particularly challenging or new. It's just an observation which we made which allows you to use existing pieces in order to achieve better end to end service restoration techniques.
As I said, it's not the idea is not novel, because it has been used for many years in some your networks even, we are talking about pure IP service, not MPLS. Here we are extending this idea to also work for any of the services which are using MPLS as a transport. I want to make is very clear upfront, that if the service is using IP as a transport, the same idea applies. So, for example, if you are using 2547 over L23P or GRE the same idea can be working for you very well. It depends on the topologist.
The key element here is that the technique presented, it's really independent on the network scale and when I say network scale I don't just mean that you are growing a single level or single area of your IGP to 5,000 notes. Network scale means that I can build my network with the IGP areas, I can build the service across autonomous systems and I still, by protecting particular elements in the network, should still be able to achieve 50ms restoration type.
So, that's exactly the topic of the presentation.
If you have any questions, please feel free to speak at the microphone during the talk, we don't need to wait the end. Let's make is very interactive. I just don't want to talk about something which is unclear for any of you.
So, what problem are we addressing? That's basically the number one question.
Many applicationsed to are don't require 50ms service restoration. They can work fine with a hundred millisecond, 200 millisecond and so on and if you have basically no requirement from the application layer to do 50ms service restoration, I don't think that this is required honestly. But, if I go to customers and I ask the strategic question, how fast do you require to convert? The answer: As fast as possible. And that's perhaps one reason why this solution has been developed. In fact, it has been developed due to the customer requests. It's not that we are sitting behind the tables and think about what else to do. The customers are requesting this reason.
Another reason, honestly speaking, why /SH solution has been developed, is that some you are trying now to fight with the transport guys and transport guy is saying no, we want to stay in place because we can achieve 50ms service restoration for you regardless of the application. And the IP guys is sitting at the table hiding and they say oh, we have no ammunition to kill them. So this is just one of the tools which can be used in order to talk that your transport guys are out of business.
It depends on the your network strategy of course, but some networks are really trying to be based on the IP end to end, especially now with emerging more and more ethernet based transports.
There are a couple of components here which are well known, which are used in this solution. One of them it's a subset of IPFRR I am pretty sure you will have very good session on Wednesday regarding IPFRR from my colleague, but here, for the purpose of this exercise, we are using just subset of IPFRR called LF8 and I'll explain more in the upcoming slides what we are doing with it. Actually it is optional to be honest.
The tunnel protection itself, when I say tunnel, I really mean the transport for a service. And this data plane job here, plus contra plane as well, but what I am trying to say is contra plane doesn't need to be enhanced. We don't define any new protocol extensions. There is nothing to standard identifies in ITF. These are all the pieces which most of your routing vendors are already shipping. Just put it together nicely in a package, but per box new functionality.
The example of the PE/CE restoration T just completes the full millisecond end to end package. /TPOD if you are running a network, you pretty much well know how to protect your links, /HO you to protect the notes. What is missing is how to protect your edges in the 50ms and how to protect the edge to a customer, let's say the PE/CE link. That's also mentioned in this talk. (PE/CE)
That's pretty much described, that some applications may require or not 50ms, but if you treat your service as the transport for others, then at some point of time it is important. What is really important also is to notice that cannot depend on number of routes and on number of nodes in the network. So, this is actually critical observation that differs, this solution, from any other convergence solution, because with convergence you have the possibility to signal the failure and then be very optimal and convert at the ingress to the networks.
Here, you actually do the local repair, he had at the failure interface of the neighbour. That's exactly the key to notice.
I mentioned about the traditional convergence. So, traditional convergence requires some had you been by had you been action. It can be IGP flatting which is basically had you been by had you been, it can can BGP withdrawal which is pretty much the edge reflector if you are lucky you have one reflector not a couple of them, to the other side. And each of those nodes would incur some delay. There is no magic that the nodes will not have delay, our measurements, and this is pretty much nothing new for you, tell us that on average, the node delay in processing contra plane packets is anywhere from 10 milliseconds to 25 milliseconds. It depends if it's a BGP update, IGP flatting and a so on. If your budget of the end to end convergence is 50ms, a couple of nodes on the contra plane packet, gives you out of the budget. We could discuss convergence in hundreds of milliseconds but not really be sure to protect you in the 50ms time frame.
There are many possibilities to actually, if you are talking about the fast convergence or convergence in a prefix independent matter to just be close to this particular line card or particular micro kernel in this case you can achieve very fast convergence in tense of milliseconds, because we are low /K FPLT you don't have to go through the kernel or you don't have to go to the RE. I am going to show you, some you you already noticed if you are using for example concept of multi pass in IPv4 unicast, you can and you have have concept also on the BGP back up bath. You can achieve very good convergence right at this particular square. Just react to go a network failure and switching the particular single pointer or couple of pointers to a backup path.
But that's just a particular case and first of all, you have to know about the event. If the event is far from you, then your chances of knowing it within tens of milliseconds time frame are weak. If the event is in the other AS and you are using let's say option C in inter AS service, the chance that is you are going to converge from the source in 50 milliseconds I would say are zero.
So, what were the particular wish list of our customers that we would try to address in this particular solution?
First of all, it has to be local. A contra plane propagation of event can be made very fast but cannot be made as fast as needed in this solution. Multi hop BFD sessions are ruled out just because cannot achieve 10 millisecond detection time when the B of the session crosses the continent. More over, if you really want to use BFD, you have to, in this timescale, you have to use the distributed BFD. With distributed BFD and the Multi hop BFD in the same time it's a problem because the BFD session, because it's multi hub, may be sent on one interface and received on the other interface. Of course there are known solutions how to do that even if you are multi hub BFD sessions and it is distributed. But, (that's yet another layer of complication and it's not guaranteed. It's not guaranteed to basically deliver you tens of milliseconds assured information about the remote end.
What was really left was the local repair. Also what was important for customers to keep in mind is that the router, which actually is doing the repair, the notice of the failure (hub) should be totally unaware of any of this particular solutions I am presenting. It is today's router which can fully do the local switch over. You don't have to upgrade your point of local repair we call it, router, in order to achieve the solution (today) as mentioned before, the local repair cost has to be really a single pointer switch over, if you were talking about a 50ms, is has to be pre programmed into the FIB or LFIB, that's I didn't mentioned BLFAs, because what they guarantee you is the ability in IP networks or LTP networks to pre programme your backup paths ahead of time. Basically you pre computing it and programming into the FIB.
It has to scale pretty much infinitely. 50 thousand service end points I think is just a number we got from one of our customers well the real number was 30 thousand and the reason they talk about 30 thousand Ps in the network is because they are talking about making all the dislambs been a PE devices. So to be very conservative we just declare 50 thousand, but, again, this is nowhere enforced that after reaching 60 thousand this will not work. And it has to work basically both inter domain and intradomain, particularly it is very Luasful to protect your transport LSPs intradomain on the ABRs, let's say. If you use the hacker IGP, you have areas or levels, then basically you can use this scheme with a very, very minimal cost because protecting transport LSPs is just a matter of number of your, number of Bs event trees in the FIB, so all the FIBs of current boxes can easily handle that and you are achieving protection for the transport LSPs, I'll try to show it on the particular slides later.
So, a couple of words about one particular building block I mentioned the LFAs. It is basically extensions to Linx day protocol, IS IS and OSPF. In order to calculate the backup path in case of link failure. On the next slide I think I have the (links) let me talk about the let me talk about the example how it really work to make every sure we are on the same page, with LFA, let's say this is the router which is trying to be smart and he knows he needs to protect this particular link. So, ahead of time, when all linkings are fine, he basically bruises from his topology and calculates SPF on behalf of other of Anti Spoofing neighbours, of other nodes he is neighbouring with, in order to make sure that those nodes will not send him the packets back if he basically tries to send it to a destination.
Let's now come back. In most of the in most of the networks we know from the production IGP sizes, it is basically 80 percent coverage is achieved, but (IGP) but the problem with LFA in general is there is no strong guarantee that you always have a hundred percent of coverage if you need to. I would say 80, 90 percent maybe are achievableed to with a good network design but not a hundred percent, cannot guarantee.
So, what is the solution if you really want to play the game and guarantee a hundred percent coverage with LFAs? Of course one solution could be to add links. Yes, you can add links, no problem. But this costs money and time to actually put some fibre into the ground.
A good work around would be to add T E links manually and then when you run your SPF, SPF sees the T link as a normal link so you can actually use this particular link as the part of your topology and in this case, you are, for both IP traffic or LTP traffic, you can achieve a hundred percent of the coverage. And of course one of the requests from the customers after we talked about the TE links itself now is to, if we are asked to do it automatically. To provide a hundred percent LFA coverage automatically in the network. The only requirement here will be to be able to run the T in this particular case. Perhaps we could do the same with the IP tunnelling, but that so far is out of the requirement list.
How would the T help? Let's talk about this example. So here on R5 /EUZ that to get to R4, my distance is 2 this way and 2 this way, so I cannot use R5 as my neighbour for LFA pro protection of link between those two routers. On the other hand, if I build a TE link to this router, this router now, it's 1 metric away from R4 so you can easily use this as my LFA router from the point of view of P L R and the same can go for building the tunnel even further. It doesn't even matter as long as you guarantee that the packet would not be loaded back to you.
So, let's talk about the solution finally. So, this is the classic picture of inter AS service, let's call it for a particular topic of this talk, but it can be layer 2 VPN, it can be other service, it doesn't really matter.
We are protecting here an LSDs which are established end to end, because in option C, you are actually relying on a tunnel between your edges. And in the same time, you are propagating the service route, it can be GP routes, it can be any other routes, essentially out of band. It can be propagated directly, usually this is propagated through two route reflecters with /KPEBGS changed configured.
So the normal situation here you see that those AS DRs are participating in establishing the end to end LSB for each of particular next hubs and you see the three next hubs, tens of 011 in all the tables in the AS BRs.
Let me talk about one particular topic that this is why I say this is not new. The technique is not new because for IP, you can notice that as long as those two AS VRs would use the same loop back basically as the Anycast address, you are automatically guaranteed then you have the protection of newer peering point. And one of the big providers in Europe I spoke to in 2000, actually has that technique deployed. Basically using the topic of ghost slow back to deliver seamless end to end IPv4 between two ASs. And it is actually only a local thing because you don't have to participate in any of the other AS operations to establish this technique. And at the same time, they also asked us, or asked me to deliver the same technique for MPLS, even though they were so eager they really wanted to do it with static label mapping between two different PEs. Of course, operationly, this is a headache, so we just said forget it and went home.
But, my point is that for IPv4 service, this, I am pretty sure, can be applied in any of the networks you haveed to. Forget about all the MPLS, you are configuring the same /PW*L net hubs and let the IGP worry about how to forward the packets. But the key information here is you can do it as long as as you have all routes in all AS VRs. That is the key message and here for the purpose of service restoration, we are doing the same. We are basically making sure that the information, one AS VR is allocated for a /TKEUFPB set of service prefixes would be also available (given) look up in the other SA VR. As simple as this.
Now, let me talk more.
So generalised model. We talk about regions here, just because it can be ASs or it can be areas. So it is really independent how far you are extending the service and because you are doing local protection, it is very easy to actually protect another boundary also locally and so on. So there is absolutely no limit (locally) as far as the side of the protection domain.
As I mentioned, one of the techniques used for IP was basically in techniques) the Anycast look back. We use the same technique here and you keep in mind this router, PLR, doesn't need to be upgraded. It can be normal router. It can support LFA, then he will do the switch over for your packets in flight much faster. If it's not upgraded, maybe he will take a few more cycles in order to install into the FIB the detection of the failure. But again it's locally doesn't get propagated anywhere as far as contra plane for the repair. In the meantime, contra plane can take its time to propagate anywhere in the network, converge and put pack nets a few seconds or seconds to a better path, directly to a peering AS VR. But that is happening transparently and the packets in flight and the service is restored locally.
No questions? I am surprised.
So, this is the description actually of the function that you are in the backup AS BR you are actually keeping the labels and the entries allocated in this other SA VR here also locally. And because we have generated a different label for the same vac, being the remote /TPHEBGS hubs, we already know that /THO kind of assignments should be looked up in a different space of the FIB or LFIB on the backup SA VR. And you may ask, so, there is no free lunch, so why is so good and where is the price to pay?
The price to pay is exactly right here. This is the price you pace because you have to store entries on behalf of other AS VR which you are protecting. More over, you can find techniques and in fact, when we discussed this with some of the customers in Europe, they had very nice ideas how to reduce that size. Also, for a sort of implementation which can help to actually reduce this size with this table in mind. Let's stop at that.
But, this is usually not an issue for any of the protection in place.
This is the new context try, so you basically receive the label packet from the point of local repair, he notices because he runs local point to point BSD or the it goes to the primary AS BR. The Hacket is heading new label with their switch to me. The look up happens in the new context, corresponding to basically the protection space. And normal switch over forwards the packet to another domain. That is essentially it in in a nutshell the operation of the backup AS BR.
As mentioned, there is no protocol extension required. This is just sample CLI but the CLI can be really vendor dependent, we don't have to reuse the same CLI. It is local box behaviour, interesting thing is that I mention that had it can also protect PEs and I'll show you in a second how the these can be protected.
So let's observe this particular example of the PEs. If you are not sleeping and paying attention, you may say that hey, but the PEs may not have the similar ethical data. They may have very VP, and they may not really similar ethically deployed across the set of PEs. Of could say this is right observation and what needs to be really protected on the backup PE is just a subset of those VPLs you really care about. Even further going, the protecting PE, the PE who is doing protection may not be really co located to the site he is protecting. As long as the site is multi hubbed. In other ways (hubbed) in this scheme you can achieve not one to one protection, but one to in, deploy one PE or two PE Yours sincerely in the network, build a couple of T tunnel to make sure the local switch over happens to a back newspaper PE and then PE can protect your most important VPNs glowly in your domain. If you are interested in more information about this particular tweak, we are more than happy to talk off line.
(Hub) so for the purpose of the protection of PEs, the label chain looks pretty much exactly the same as normal, except we are adding this context label which corresponds to redirecting the packet to a backup. This is a as simple as this. There is nothing else.
If you would like to use such a scheme with IP tunnels, there is nothing particularly preventing them from doing that. It is just the IP header destination address would have to point you to a backup context as well. That's no magic here.
And for the PE/CE links, this is of course not visible in the domain or inside your IGP. So for PE/CE pro protection because this router will not be aware of the PE/CE failures, /TOUF do the PE/CE FRR and I don't want to spend time because this is a well known technique.
A couple of more words about how to really scale your network and scale your domain. There are a couple of approaches to scaling the network.
One could be with the introduction of the hard core LTP. The other things discussed were the aggregated /TP*EUBG ideas. For the purpose of scaling the most, I personally, and I think many people are coming to the conclusion, that using /AEUBLD BGP, if you are talking about end to end MPLS as opposed to IP tunnels, is the solution of choice. Because with LDP you can provide and end to end label distribution for your hubs and locally this technique plus normal LDP in the IGP can provide you with the glue between the A BR, or AS BRs in each region. That go be in my opinion the most scaleable design for large scale networks using LSPs.
And of course this technique, if you use it for example at the A VRs, doesn't require you to install all the directly at the FIB, all the prefixes for the BGP next hubs. You are using the context of indirection to save the space and no so much the space but also to increase the speed of switching the data plane at the failure time. So, the concept of indirection has been designed really to optimise the switch over performs and sometimes you may here about this as hard core FIB, in many different ways, but this is actually here for the purpose of speeding up switchover between entries in the FIB.
Coming back to this inter domain model. If you basically use BGP plus label plus LDP local net area plus your service, distribution of routes usually also BGP, you can achieve quite well scaling which meets not only the requirement of 50,000 nodes, but also the requirement of 50ms end to end convergence.
Just to summarise again.
This technique doesn't require any protocol extension. It works with the current protocols. We may use some of the protocols as enhancement to the idea to let's say to correlate label blocks between different AS BRs or different PEs, if they are required but this is a total add on, if at all.
It is a local box decision. It is also important to keep in mind that the box you are protecting doesn't need to be aware. So you can basically protect an existing box with a new box which is smart and can do the protection. That's basically the very important observation.
And it's applicable to transporter service LSPs,. Works intraand inter domain and basically we have all the pieces place to build this solution.
So, thank you very much. Please ask me a question, if not here then perhaps at the breaks or send me the e mail or to any of your colleagues from Juniper. Thank you.
(Applause)
CHAIR: You certainly demonstrateed to me that I couldn't earn my money in designing networks any more. Are there any questions? Are you all awake?
AUDIENCE SPEAKER: I think you could design networks Daniel, just not ones that are so complex that awful our income goes to the vendors.
SPEAKER: Yes.
CHAIR: Would you like to respond to that question?
SPEAKER: You are designing the networks in a simple way, but as I mentioned in one of the slides, cannot achieve 50ms end to end, even IPv4 unicast conversions across domain. You can achieve it within a domain. We have some results. But not really across demains if you really want to provide some of the services other than IPv4.
AUDIENCE SPEAKER: There is a serious question whether anything below 200 milliseconds is really useful inter domain and, with fast BGP convergence, with BFD etc., etc., you are close enough to actually do it. It's like the last presentation we saw about inter domain QoS, that was the most, that one has to have the award for complexity. But to be fair to it, at least it wasn't a vendor trying to sell it to us it, an academic doing research and that's valid. But having things which are so complex to cover the fact to eat my op ex and cap ex, I can just provision a circuit, you know.
SPEAKER: Okay. So let me remind you that my start at the talk if your best of my knowledge /ET in the convergence, 200 milliseconds. It's not the talk to you. If you can limit to 200 millisecond, that's fine. We are other tools to do T about complexity of this, I, on purpose, including a CLI showing just two lines configuration. That's it. How complex, how less complex it can be? It is basically the box is doing for you the work. It just listens to BGP updates and installing the state and that's it. I don't know if you can make any less complex than that.
CHAIR: Any more questions? Well, see Robert in the hallway then. And thank you again.
(Applause)
CHAIR: Malcolm. He promises this is going to be very short. This is Malcolm Hutty and he is going to report on the corporation taskforce. +/AOEBG
SPEAKER: I can probably do this this the time it takes to set up some slides. This is going to be very short because we did this all at the last RIPE meeting. It's the final report from the enhanced corporation taskforce.
Briefly for those who weren't there, this taskforce was set up as a response to concerns from some governments about bottom up, government /RO processes for Internet resources. It was set up to give a response to that. We decided to do things: One to create to explain what bottom /*F op /UPL /TKPWOUP process /R S like the RIPE community are and why they are a good thing and secondly to decide what to do going forward about relating better to Government in a process that's known in this political discussion as something called enhanced cooperation. We wrote the report. I presented it to you at the last meeting. Everybody seemed happy. We were planning to do some more about what's going on forward. But, we proposed setting up a working group. That working group has now been established to dot stuff going forward.
So, the final reports is essentially the same as it was presented at the last meeting and it's on the taskforce's website so I'd like to you just simply formally accept that report as it was is he last meeting and attend the enhanced the cooperation working group that will be in the next door room on Thursday morning.
I'd also like to say a quick word of thanks, particularly to Chris Buckridge from the NCC for the work he has done helping support the taskforce and if you can now formally dissolve the taskforce, that would be good.
CHAIR: Okay, Mr.�Chairman?
Rob, Chairman of RIPE. In the first place, I would like to thank you Malcolm, as the leader of this taskforce, you and your group for producing an extremely useful and informative report, thank you.
I think I support your conclusion that basically what the taskforce was set up to do has been done. So, the taskforce can be dissolved with our thanks.
Also, the strong recommendation from the taskforce to make this a bit more part of an ongoing activity has been followed up and between the last RIPE meeting and this RIPE meeting work, a working group has been constituted which will meet first day working I think for the first time. So I think we can accept it unless there are dissenting voices.
CHAIR: Is there any discussion? I see no discussion.
ROB: Okay, this is accepted and the taskforce is discharged and all our thanks to you and your colleagues for a job well done. Thank you.
(Applause)
CHAIR: Okay. Without any delay, I ask Richard Barnes to take it away and talk to us about emergency services and how that stuff affects us.
CHAIR: Okay, guys. It looks like these problems are insurmountable so I am calling an impromptu coffee break and I would say that we reconvene here in half an hour. That would be at 3:30. I apologise for the inconvenience and we'll have this talk before we'll have to just run over a little bit. So feel free to leave the room, we won't start before half an hour's time.
(Coffee break)
The session reconvened:
CHAIR: Could you please be seated so that Richard can start. Apologies for the rescheduling. We will after Richard is finished with his presentation and we had sometime for discussion, we will immediately start with the Address Policy Working Group session so there will not be a formal break between the two sessions. It will just flow into the other. I would like to ask you if you need to leave after the session or need to get some coffee, please to do so quietly so that we can conduct an orderly meeting.
I don't want to waste any more time. Richard Barnes from BBN about emergency services.
SPEAKER: I am glad to be here, this is my first RIPE meeting and so far so good I am glad to be able to talk to youed to.
/WA*EU wanted to talk abouted to is what's happening with next generation emergency services, which means emergency services, communications and emergencies in device that is communicate for IP.
By way of background I work with BBN Technologies. Most of my work is involved with working with the IETF and Internet standards and security and standards for emergency services and for GI location. I service the secretary of the IETF Working Group and I am on the programme committee of the emergency services workshop which coordinates standards and implementations of next generation emergency services.
So, what I'd like to talk about to is sort of an overview of what we mean when we say emergency communications and next generation emergency communications and how we are starting to address that problem over IP.
So, what we'd say when we say emergency communications is basically two things: The first is much more familiar to us as end users of the telecommunications system. Which is the citizen to authority emergency calling. It's 11 /# in Europe, 911 in US. In the UAE, there is different services. But these all have, with many other service around the world have the common property that based on where you are in the world, if you dial this dial string into your phone you'll be connected to someone that go respond to your emergency.
And so, the question is if I am an IP device, and doesn't have inherent notion of my location F I plug my laptop into the network here and pick up a soft phone and dial 999, how am I supposed to be connected to emergency service so that I can have my emergency responded to?
The other type of emergency communications we talk about the so called authority to citizen authority communications. This tend to be something people have less contact with in their lives but is still critical in a lot of applications. In this sense we are talking about /WORPBGS that go out from some central authority to many people. They tend to be targeted base on the geolocations. This alert could be sent to everyone that's in the danger of an earthquake, hurricane or whatever.
The challenge here is if I am an IP device and I need to receive alerts about something, how do I figure out who is supposed to be giving me these alerts and how can we distribute you know from the perspective of distribution, how can we distribute these alerts in an effective fashion and they are /R G going out to hundreds of thousands or millions of people in a close geographic area?
So both of these functions are implemented in various forms in networksed to in PSTN, but increasingly things are moving or to IP based telephony. We want to use VoIP.
So again, why do we care about emergency communications over IP? We have got all sorts of devices out there that look recollect act and smell like phones but actually one on IP. So i phones have packet interfaces both over the cellular network and over 80211. The 3 GPP is going to be VoIP on a grant scale and cellular. Back better /AOES have IP interfaces. There is loads of mobile devices.
/KAOEPL are using IP devices for telecommunications. When I travel internationally most of my telecommunications are done over VoIP because I don't have a cell phone that works all over the world. So, I am engaging in communications over VoIP in many parts of the world so it would be good to have emergency communications work in the same which I would expect them to with a normal phone.
So, the goal of this whole effort is to enable my voice over IP device wherever I am in the world, uniformly to be able to ask help to make emergency calls and to receive appropriate emergency warnings regardless of where I am on the Internet, regardless of where that is geographically in the world.
So, this has been a problem that's been addressed in a variety of organisations around the world and in various areas of technology. So what I am going to present is kind of the high level of architecture that came of the IETF working group for how to do emergency calling over VoIP. And I'll talk about emergency alerts and authority to citizen communication in a moment.
So the basic model for emergency calling over IP, at least from the IETF is to complete an emergency call in three steps. The first step, because where my emergency call gets routed is entirely determined by where I am and who the emergency authorities are for that location. So, when I am here, I would want help from the Dubai police, when I am at home in Washington DC I would want help from the Washington police and the only difference, the only way to distinguish between those cases to figure out where the caller is.
So, there are a number ways to approach this. If I have GPS or if I am, is it user willing to enter this location into the my IP device, we can use that location. The I FTE group has also been working on which in which IP devices can request location information from their local network, so that's a network that has some physical relationship to them. Much like a visited network and cellular network so that that local network can provide some information about their location.
So, step one is to figure out where the caller is. So that we can start to figure out how do deliver emergency services.
Step 2, is to route the call. As it says here, which is to take that location and use it in a query and actually the rather owes are reversed here, it should be location going up to the database and the reference coming back. So we use this location that we have got from some mechanism to figure out what the context is for placing an emergency call. So that context, the primary element of that context is, some sort of IP level contact information for a public safety answering point. So answering someone that will pick up the phone and be able to respond to my emergency. So, in the case of IETF standard standard SIP emergency calling, what you get back from this mapping database is a SIP URI to place a call and deliver a call to a public safety answering point.
The answer here that's on this slide, what happens is you know, this is kind a profile of this general strategy where I have high laptop and I have got my soft phone running say and I get my location from the local network. So, say I query the /# 0211 network here and it knows which access point I am connected to and it /PELS me okay you are in the Dubai in the main meeting room here at RIPE. So that's where you are. I then put that location into my call signalling, I can route that location in a SIP message that goes to my proxy. This proxy again to be anywhere in the world. So if I were using an American voice service provider I could send my location and that SIP proxy in my American provider would be able to go back out to this database and determine where I should route the call.
So the proxy would then query with my location to this database and get back a URI to which you would then direct my emergency calls and ideally, if this all went right, my call would go first, the signalling would go back to the US get mapped and then sent back to a PSAP in Dubai so I could get my emergency response and some help.
Another way it can happen one problem you run into is that these PSAP over the course of the emergency call wants updated location, especially from mobile users that might be using. So, I am in the course of an emergency and in a car moving down the street and I want a response wherever I am at any given moment, the PSAP is going to want current location information on where I am at a given moment. Not where I was when I sent the call at the beginning.
So, to accommodate this, the IETF has defined a model where we deal with location by reference instead of by value. So in that case when I query from my location from the local network, I get not a value, an address or latitude or longitude, instead I get a URI, and that's what I include in my signalling. In that case, this mapping database still needs access to the actual location, the value of location in order to do the mapping. So, the proxy here sends the reference to the database who then talks back to the location server to get the value and returns the mapping information, as before. And the call goes on. But in this case, what the PSAP gets is not the value of my location which would be a snapshot of where I was at one point in time. Instead, it gets this reference that got sent all the way along the chain. And so, at any subsequent point, the PSAP can go back over the Internet to this location server that's in my local network here in this room and ask, well, where is Richard now? Where should I send the police to go help him? Or to pick him up and arrest him, who knows?
So, we have got these two models for doing emergency calling, one by value where we get an actual location value from the local network and send a long from the local network or from my answering or from some third party source and we send that value in the call signalling so that the PSAP knows where I am. And we have got the second model, where we get a reference to my location from the local network. And send that along so that the PSAP can get updated location for where I am at any given moment. (PSAP)
As an aside here I'll note there are privacy concerns that go along with that. Also a focus of the i.e. TV a geolocation privacy working group, if people are interested, we can discuss in another context.
So with respect to authority citizen communication, this is a notional architecture I have noted because this is an area where there is just starting to be development in the Internet community. There is BoF proposed for this IETF. But they are starting to build some interest in the Internet community about enabling this. The state of the art and authority to citizen right now is there is many wireless broadcast techniques out there in the US at least the cellular industry just agreed on a standard for using sell broadcast for emergency alerts. So there is a few sort Mac layer or physical layer techniques out there but no techniques that are general to the Internet so that all IP devices regardless of how they are connected can receive these alerts.
So, one way you might do this, again, this is a notional architecture. We can again use this location to service mapping database to enable authority to citizen communication and in this case the way it would happen is that I would, you know, again get my location by whatever means, from a location server in the local network or by entering it in, and instead of letting the network do it for me I myself would go off to this mapping database and figure out instead of where I should send my emergency calls, where I should ask for emergency alerts and so once I get this reference to a emergency authority back from the mapping database I can send a registration to that alerting authority so that if there are any alerts I should be getting, you can send them to me because he knows where I am because I have told him.
You can do the same thing again with sort of delegation framework, where, for instance, you want to put, take the end point out of the loop, if all end points are supposed to receive this, instead you can use this as a network configuration function where a network element somewhere in the network can use a location resource to figure out where it is and act as a relay by figuring out what alerting authority you should be listening to and registering for alerts and relaying alerts down to end points that are connected to it.
So this is one avenue perhaps towards scaling. So that alerts are sent once to these consolidated network distribution points and then van out to the end points connected instead of this case being send unicast to every end point that's out there. So like I said, this is still very early stage, this authority to citizen work but it's something that there has been a lot of interest in the ITU, no other standards organisations, it's just started to be picked up in the Internet community.
So, if we are going to think about implementing all these things. It's a nice framework, it all works in principle. What do we need to be actually out there?
There are three basic requirements, as you might have guessed one of them is /HROEFPBLGTS because location is the thing that establishes the context, that dictates how all these things function, how calls are routed and how I receive alerts. How anybody knows to get in touch with me or how I know who to get in touch with for my emergency.
So location of callers is the critical, the key stone of this architecture.
The second thing is that you need this globally distributed mapping database to figure out any point on the earth who it should call to get emergency services.
Finely we need to take all your emergency services and any that are developing and make them reachable over VoIP and make them such that it's secure and reliable.
So, I have highlighted the first one of these, the location aspect. Not just because it's the one I have spent the most time on and have the most interest in. But because it's, I think the one that has most relevance to the most people here. The location service mapping databases are likely going to be the function of local governments and their contractors. Centralised emergency authorities. And likewise making emergency services reachable over IP is going to be a function of the guys that run emergency services, not of you know the Internet community at large.
So it's going to be really up to a lot of different people. Not just local authorities to make it so that Internet end points can figure out where they are. You know, no matter where they are in the Internet.
So, I'll talk more about that location thing in the next couple of slides.
It's worth noting that there are a couple of additional things on top of this that might come up and you might see as requirements on your networks as you know, as jurisdictions you are making regulations about how to support emergency calls on IP networks.
So, what some jurisdictions are looking into a requirement that you know right now if I have a GSM phone without a similar card, I can still make emergency calls on it in several countries. Because it's an emergency call. It's a working phone. So I need to get access to the network and place a call and that's mandated by local regulations in several countries.
So, regulators in those countries at least are interested in how that translates over to IP. Obviously a problem that cuts across many layers in the network stack including network ago /SES control, access to voice services, with you that's a problem that of interest to the regulatory community, to the standards community right now.
Another thing that's being, that's again in the early stages, but being discussed in some of the communities that are developing requirements is that there may be some requirements to prior advertise emergency calls or emergency call related traffic within IP networks in order to ensure that those calls go through even if the network is congested.
So, let me delve in a little bit to this requirement for location information. So, as I have tried to express, location is really central to this emergency calling and emergency alerting process. It determines how I get my calls to the right PSAP. Once the call is in place. It enables the PSAP to send responders to me even if I can't tell them where I am. If I wandered out on the street around here, I wouldn't be able to say where I was. So I would need some sort of automated facility so that the PSAP could send the police to where I am.
Again in the emergency alerting case it determines which alerts are appropriate for me, so it will let the alerting system know where I am in an area that's in danger of a natural disaster or some sort of attack or what have you.
So, like I said, I think I said before the access network, the physical network to which my host is connected has a kind of a critical role in locating a device. In the IP community we are kind of used to abstracting for physical things and enabling host to say communicate in any other hosts in the world. In this case the network that a host is physically connected to is really the one that's essential. Because that's the network that has a physical relationship to that host. If it's a wired network that network knows what wire a host is connected to. If it's a wireless network, what base station and you can do more advanced things like triangulation F you have a device that can't determine the location on its own. If there is no GPS or if the user can't provide it, then if you only assume that's the device is connected to an IP network you really need the physical access network, the host is connected to to help out with location.
So, in support of this emergency calling, access networks are going to need to location enable their networks, is the phrase I guess I use. And what that means is that they are going to need to figure out a way, they have networks kind of know where they are at some level, they realise it gets thrown out in different databases and pieced together. But there is going to be a need to create some sort of function to bring all these disoperate pieces of data together. We did a demo where we patched together information, we went from IP address to say Mac address to say AP Mac addresses, to wireless point access address as /TH PBD then mapped the location. There will be a need to do that sort of binding of all this network management information in order to map what a host's identity is to where it is. Then there will be a need for a provide some sort of information, interface to this information for users and to PSAPs.
The good news about this is it's not just an emergency problem that needs us. There is also a lot of non emergency applications that would really like this location for IP based services. That's a whole other talk talking about location based services over the Internet.
So just to give some examples. Location based advertising has gotten a lot of interest in the open mobile alliance. Especially they have got a whole location based advertising working group there. But also on the Internet there is interest in that. There is interest in friend finding social networking services based on location that are starting to show up in the cellular communities nowadays. That could also be implemented on the Internet.
And you know, this location to service mapping thing can just as well be generalised to Monday emergency services like pizza or coffee or what have you.
So, the hope is that in addition to these regulatory mandates that are likely to come down for some sort emergency services support in IP networks, that there will also be some intent I was created by these non emergency services so that networks will be able to make some money off of these location facilities.
So, you know, like a lot of things on the Internet, in order for this to work it will need to be standard. So in the interest of making it so that hosts only have to implement a small number of protocols to get their location and that networks only interest to deploy one, the IETF and some other organisations have defined a small number of standard protocols by which a host can get its location information. So they have extended those are the extensions for DHCP, for distribution location information through that. There is a protocol called held, it stands for HTT enabled location delivery, that enables a host to go out and ask for its location in various forms and get it back, held can also provide measurements and do some advanced things. The open mobile alliance have defined a protocol called Supple and which can be used in certain cellular networks.
So, the bottom line for this in the context of emergency services is that in order to guarantee the access of location for the purposes of emergency services, an access network that has you know, end hosts connecting to it will need to provide at least one of these interfaces for hosts to use to get their location and then hosts will need to implement a number of these mechanisms to make sure they can plug into any network and still get location.
I have outlined here and sketched here on the bottom how this held thing works at a high level. The idea is when I connect to a network, my host will go out to a DHCP server and as part of this, it will get its domain name for the local network or for itself as a host. And so what the local network can then do is provision some NAPTR records in the DNS here, we have defined a NAPTR service by which this domain name can be used to look up a URI for a location server. I then go off and use this http protocol to get my location. It's a fairly standard service discovery and service application usage.
One nice thing about this being over http though is that this location server can use any number of location methods behind T it can have a wire map database if it's a wire thing or have a database of access points to figure out where a host is. It can talk back to the host itself and request measurements of it out of bin and it can ask things about the network, it can peer out to the network management system to figure out what's connected to what on a query by query basis.
So what the IETF has defined is this abstract architecture T hasn't figured out where a host is, but it's defined how to host asks where it is from the network.
This is one of basically /SWRO Internet standard mechanisms right now.
So, these are the elements that we need, the elements that we need to make emergency services work are you know location, location to service mapping and then IP accessible PSAPs. There is a number of bodies throughout the world working on this, that the general IP calling architecture was laid out by the IETF. And then emergency calling in the ECRIP working group. Then there is a number of networks that use IP, the 3 GPP in the IMS, OMA in their user plane protocols. YMAX, etc., etc.. that are looking at how to implement emergency calling in their specific network architectures. In addition, there are some organisation that is define standards for data interchange that are defining emergency relevant data format. The open geospacious consortium specifies how to talk about shapes on the earth, how you talk about the points on the earth and oasis, the expansion of acronym I can never remember, they have defined a protocol called the common alerting proposal column which is data format for emergency alerts.
We have got standard bodies working on this. We have got regulators looking at how they make regulation that is make sense for VoIP. So they have got lots of regulations standing around for how you require emergency services from PSTN networks where the access and calling network are the same. The difficulty with IP is that the access network, the IP access is /KPHAOEL de/PUPLed from the calling network, the VoIP service that you are using, so this is an insure they are having to deal with in terms of how they regulate all these entities.
So you have seen participations from a bunch of different organisations in Europe in particular the European Community has been involved, the German, Norwegian, British regulators and US Government has been involved as well.
We are starting to see some involvement from network operators from Deutsche Telecom and British Telecom among others. In terms of how they are planning on extending emergency calling that they haveed to to support VoIP emergency calling. Mainly the operators we have seen participation from so far from been legacy PSTN operators that have an existing emergency calling capabilities that hair extension much we haven't seen so much participation from ISPs that are pure ISPs. That's an area with we'd like to see more participation.
Final leave seen the guys actually one PSAPs getting involved in this because they have actually been already getting emergency calls over VoIP and they have no idea what to do with them.
So, the way we as a community have tried to organise this, a bunch of folks from the IETF observed that this sort of chaos with standards and implementation making was going on and tried to start an activity to organise it and we called that the emergency services workshop and what that activity is that every six months we have held a meeting that tries to get together all the different entities that are involved in this process. So, including all those things I talked about on the last slide, standards organisations and regulators and network operators and PSAP operators all the different points in the value chain of emergency calling to talk about how we are going to do this and how we are going to do it in a standard way.
The main goals are to align all the different standards that are going on so that we have well defined relationships and an IP device that wanders were you know a regular IP network to a 3 GPP packet access can still do emergency calling in either case. And make sure everything is consistent.
And we have tried to coordinate all the deployment efforts that are coming up as well. I invite people very strongly to participate in this from the perspective of standards organisations if you are active there or from the perspective of being a regulator or a network operator. I don't think there are any PSAP operators here.
A question?
This is my last slide. If you want to learn more about this, talk to me here or send me an e mail. The workshop has a website and we have a mailing list for discussion of these activities as well.
So... thank you for having me here. If there are questions.
CHAIR: Thank you, Richard.
(Applause)
CHAIR: Questions?
AUDIENCE SPEAKER: I have got a question criticisms of your basic architecture. My Malcolm Hutty, I am from /HREUPB us but entirely personal here. It's criticism of your basic architecture, one aspect it have that really scares me and it's about the fact that the location server is a network site service rather than a client site service. In other words, that the fact that your querying the network is discover where I am rather than asking a GPS chip on my laptop or something like that that I can control. I am very used aboutity use of privacy side. I know that they are looking at this and certainly for the things that I don't want anyone to know that I am here in Dubai so that I don't get burgled at home and the fact that I don't want my watering spouse to find me, those things geo/PWREUF are looking at that that's fine.
I am concerned because I don't trust my SIP to implement any of this stuff properly anyway. It will break. Those /THUL /SRERPLS that I as a sues err have suffering. I am /WOFRG about the selling the database and forces me go into auto set of terms and conditions that supposedly allow me to consent to all of that that I actually don't really agree with at all. I am also worried about conditional access, the fragmentation of the Internet. I am worried about service and content that's available at the moment being made continual upon me providing my current location information and it being the right location information that will be verified and I won't be able to lie about because it's a network site service. If there were /SHRAOEUPBT site service I could lie about it and I could still get access.
SPEAKER: Let me pause you there, it's not an / PB inherent feature in the architecture for the location to be provided by the network.
AUDIENCE SPEAKER: I am worried about the fact that you are removing control of where that location data is coming from from me the user where I can directly control both whether I give it and what it says /AEUPB indeed lie if I want to and moving it to the network where it will be verified.
SPEAKER: Again, this is not an inherent part of the working. User provide a location. GP Yours sincerely provided location is equally usable to location from the network in this case. The trade off as you say, is versus viability. One major concern of PSAPs is that this opens up if you have not versus viable location, it opens up the door to lots of fraud, I in Dubai could place calls it any PSAP anywhere in the world by lying about my location. There is a security trade off there. But as you say
AUDIENCE SPEAKER: You are worried about me as the user lying and saying that I am in London at the moment when I am here in Dubai and lying to the Dubai authorities, or the London authorities not asking them to send out a fire truck in London when I happen to be in Dubai at the moment, that's your worry, that's why you have chosen to verify T
SPEAKER: It's not mine, it's a worry we have heard from PSAP operators. Because there are tremendously worried about denial of services.
AUDIENCE SPEAKER: Basically /T P /TOUPBDZ to me like I have chosen a design that assumes that it will be a network site location service because you want to override
SPEAKER: Again if you want to fill in location, all of the technology works. If you want to use a GPS, all it have works. The reason we have looked at network location, is is that not all devices have GPS, my laptop doesn't certainly have GPS, many phones don't.
AUDIENCE SPEAKER: This doesn't exist in the network either. So it's got to be built one way or the other.
SPEAKER: Fair enough. Assuming that there will be devices without some sort of positions facility. Remember GPS doesn't work in this room either. If doesn't work in many indoor locations. Assuming
AUDIENCE SPEAKER: I have heard those arguments before.
SPEAKER: Let me continue this off line. The point taken. There are trade offs involved in terms of privacy and verifiability, this is a discussion that goes on. I'll be glad to continue with you off line. (Verifiability)
AUDIENCE SPEAKER: I am reed. I want to go back this this issue of verifiability and actually turn Malcolm's argument on its head. (Verifiability) what if we have a scenario where the Internet service provider isn't verifying the location of somebody and the service provider gets it wrong?
SPEAKER: Right. So that's a situation where so
AUDIENCE SPEAKER: If I remember correctly, it was a case I think in Canada earlier this year, where a VoIP provider was given emergency service information and sent an ambulance to the wrong location and the person died.
SPEAKER: Actually that's a situation we seeed to in the PSTN where they get the location wrong or they send people to the wrong building. It's a situation that will be new because it's over IP and it's a new entity.
AUDIENCE SPEAKER: If network provider is saying I guarantee this location is correct and he gets it wrong, you are then liable?
SPEAKER: Yeah.
CHAIR: Thank you. Patrick and then Olaf.
AUDIENCE SPEAKER: Patrick, CISCO. I think people in this room should remember that they are already some problems like you pointed out where the current system that we have and the goal of this is not to create something that is not bullet proof engineers but we have to make sure the system is up to date doesn't get worse.
Ed to I hear numbers, when I talk to PSAP operators that between 65 and /# 5 percent of the calls, depending on who you ask, are actually calls that are not for emergency services. The most common case for people calling is that they are buying a used cell phone and they want to make sure that it's possible to call because even without a SIM card and without SIM card, that's the only number you can call. So people use that to see that the phone works. It's also the case that, like you pointed out to Jim, that alreadyed to there are some misrouting that is happening, not only by mistake bus databases are not updated but also just because you already haveed to have extensions to, for example, enterprise phone switches where the call is coming from the extension that might be on a complete different place, but the location is the location of where the head office is or where the phone switch, if it is the case that anyone of you happen to visit a PSAP, type in your own phone number and just check where on the map they think that you live. I tried. I was scared. After that I actually figured out what coordinates I live on and I have that taped on my phone so I can tell them.
CHAIR: That's a good suggestion. It wasn't really a question. Would you like to respond anyway?
SPEAKER: Well, I'll just reiterate that what Patrick said that yeah, false calls are already a huge problem in the PSTN based emergency calling system. My favourite example recently is I was talking to an Irish PSAP operator and said he got a call on Christmas Eve from a whom who was calling because she hadn't gotten the Turkey in the oven on time and the operator said well that's not an emergency. She says well my husband is going to come openly and he'll kill me and then you'll have an emergency.
CHAIR: Any more questions? Then I'll take one.
Given Malcolm's concerns, and the whole verifiability thing. In this architecture, is it possible to actually have user control even if the location is provided by the network to say, to have a sort of a gating function where you forward the position or not? For instance, if I am calling someone who I don't want to know my position, I can say, no, don't send F I call 999, I can say send it and it would have an attribute that says this is actually a network derived location so they trust it more. Is that possible in this architecture? To have the user device or have the user control whether the location is sent
SPEAKER: There are combinations of what's allowed in terms of client provided location and network provided location. It's going to be a function of what the voice provider will accept, what the PSAP will accept, etc.. You know, PSAPs, it may be that, from what I have heard, they won't drop calls that you have unverifiable location but they might treat them pour suspiciously and prioritise them lower in the queue, but there is certainly nothing will prevent that from happening in the technical architecture. There is a whole field of security and privacy questions in terms what what the constraints are that the operators have and what users have and what voice service provider have in terms of constraints that is still being worked out and on top of all that, what the regulatory liability framework is.
So, I guess, and I'll being a little abstract here, it's still we are in the point of development where a lot of these questions haven't been decided yet and where will ultimately end be you will jurisdictional in a lot of cases. In the most general case the phone you are using is not a phone you plug into the wall. It's a dumb end device. It's a piece of software that can be configured to do what you as the user tell it to do.
CHAIR: I guess the upshot of all this is if anybody is interested in the work, to look at the work that the IETF and participate there and if you are interested in how it might be abused, then get involved with your network operator and your local emergency services.
SPEAKER: If you are interested in the Internet technical aspects, get in touch with the working group. Otherwise with these larger concerns about privacy etc., there is an emergency services workshop in this group. Like I said, there is network operators and regulators on these lists, at these meetings. They are much better for these multi level sort of discussions than I alone am.
CHAIR: Thank you Richard.
(Applause)
CHAIR: We will have no break and we will go into the Address Policy Working Group now.
SPEAKER: This is now the Address Policy Working Group and welcome to address policy. We are struggling with the wonderful of computers, so I am, we'll just improvise.
The first thing on the agenda is of course agenda bashing.
As I said, welcome to the Address Policy Working Group. This time we actually have four full time slots to, well to discuss our open policy issues and suggestions that you might have. This was done basically in seeing that the time slots we had last time and the meeting before that were just not enough since so much seemed to be happening.
First thing on the agenda today is agenda bashing and this is going to be a bit longer than usual since we have so much time. This is again over the four times or the four time slots spread over three days. First of all, I will give a very short overview of the concluded proposals since last meeting. Then we will have an overview from Phylis about the current policy topics discussed worldwide. Then we will discuss the open policy topics in much more detail.
On Wednesday, we have sort of things that are not yet formal but might warrant discussion, some crazy ideas, things that, well just popped up and could need some feedback from you.
I am going into more detail on the different days now. Well, today it's first of all administrative measures and the first thing is from the RIPE NCC is taking notes and thank you very much for it. It's not easy to do that, so again, thank you much
Then we will go, approving the minutes, discuss about changes of the agenda. As I said, a short overview of the concluded protocols and policy topics by Phylis.
Then I will give a sort overview on the new proposals that have come up and we will write, enter right into the discussion of things that are related to PI space and special case exceptions to the normal policies.
Tomorrow, we have two time slots: We have the early morning time slot starting nine o'clock where we will continue with the PI addressing and then we will go to the end of IPv4 stuff, specifically this will be the transfer protocol from Remco and before that, we will have a presentation from tomorrow vest how transfer policies around the world and the impact on things. To give you background information on discussion on the, on our transfer protocol.
There Hans /TOBS plenty of discussion so we really can take our time this time.
Tomorrow we have a second time slot between 11 and 12:30 where we will continue discussing the end of IPv4 proposals, they are two proposals from Philip Smith on the table: One is to restrict the way RIPE NCC gives out addresses from the last /8 and the other one is about efficient use of historical IPv4 resources. More details about that tomorrow of course.
And then we have some proposals that touch other working groups the one is the certification taskforce coming up with a proposal to give PA space holders a resource certificate to help in routing and everything. And some discussion about rewording of one of our policy documents to take into account a format change being discussed in the IETF regarding AS numbers. 4 byte AS numbers actually.
On Wednesday, we have well all the sort of not yet fully organised things that we might want or should discuss. You will notice that the sequence of letters is a bit odd. This is I have left the letters the way they are on the printed agenda, but rearranged the different items a bit to sort of make the process more smooth. So, some more discussion on Wednesday.
That's so far for the agenda. Now, the question is have I missed anything? Is there something else you want to see on the agenda? Of course, anything can be added later on to AOB, but if you have something right now, we can put it on line so people can see it.
Okay, I see nobody jumping up and down than it's right to the minutes.
I have sent the minutes from the last meeting in Berlin to the list some six weeks ago. I received one comment from Peter /KO*BG who wasn't quoted completely correctly and that /KPHOPBT has been integrated and besides that I have not received any feedback. So is there anything else in the minutes that needs correction or that you want to add or modify? Okay. Again, nobody jumping to the microphone, so, I declare the minutes to be final.
And then we are nicely up to point B on the agenda. I have some issues with the other bit this time. I am sorry for that, but it's actually point B and not point D. That's the concluded policy proposals.
They are actually five since last time and 2007 04 have been finalised before the last meeting actually but it's here because some things have happened later on. I will quickly go through them in sequence.
2007 04 is the global policy for the allocation of ASN blocks to the regional registries. This was accepted in our region before the last meeting and since all regions have accepted it, it went then to the NRO and irk ASO and everything and has been ratified by the board on July 31. So this is now a global policy which before it was still under discussion.
2007 09 was the policy about the cooperative distribution of the end of the IPv4 free pool. Basically, if one of the regional registries runs out of addresses, the other regional registry that has the most addresses has to give some of their addresses to the other RIR, that debenture have enough support in the different region. That would have to be a global policy and other regions completely rejected it so it was decided to are draw it in our region. So that's off the table.
Then we had two proposals from who came up in Berlin and presented his ideas and people really disliked them. So, he withdrew these two proposals right away in Berlin, so they are off also the table.
He knew that they are a bit extreme, but sort of you have to set an upper boundary for things.
Then we have 2008 03 which is the global policy tort allocation of the remaining IPv4 space. Basically that's the tinge that as soon as I can run down to five /8s left, these five /8s get distributed to regional reg /STRE. Every /SREPBLG statutory gets one /8, than ICANN is done. That has been accepted in our region. And I give the word now to Lewis Lee from the NRO who has been volunteered to say a few words on what's happening in the NRO regarding that. Thank you.
SPEAKER: Good afternoon everyone. My name is Louis Lee and I am this year the chair of the NRO Council. This global policy tore allocation of the remaining v4 space has been accepted in four of the five regions and in the APNIC region, this morning the chair of the APNIC /S*EUBG policy working group has sent a message to the APNIC Executive Council to accept the policy. So, once so once that's been accepted, the NRO Executive Council will synchronise the language in all five the policy proposal to a single policy proposal to pass on to my group, the Number Council to process and in turn hand it on to IANA, and the ICANN board. Anything questions on that? Thank you.
Okay. Thank you for coming up on pretty short notice and letting us know what's going on.
Then we have 2007 01. I am pretty sure you are aware that have proposal. It took us long enough to get to consensus. There are still some voices that are not completely happy, but it's a very complex thing and well, there is no way to make everybody happy with that. But we seem to have achieved rough consensus and this is now accepted and will get implemented. And I have asked Andrew from the RIPE NCC to say a few words on this, but I cannot see him right now. Okay, he is up there on the microphone. Thank you for coming up.
Andrew: Particularly on this proposal, we understand there is quite some questions about the implementation of it. Tomorrow, I think on Tuesday, in the GM, there will be discussion on the contractual side of this proposal, so I won't go into detail on that side today. For the rest of the implementation we are looking at a phased approach where phase one will exist of new requests which will come in and we expect to be ready for the implementation as of February 2009. Phase 2 had be the retrospective part of the proposal and we will like to give a presentation at the next RIPE meeting on how this specific implementation will look like.
Okay. Again, I see nobody storming to the microphone and discussing that this is not the way to do it so I think this is a good approach. All of you that /RAOEFRS and local registries are of course welcome to come to the RIPE General Meeting on Tuesday, this shift in week it getting me confused on Tuesday the RIPE General Meeting will discuss the contractual impacts of this proposal and how the contract would like like and how the charging scheme would be modified and so, this is clearly out of scope for address policy, but it's of course affecting you so if you represent an LIR, please go to the AGM and well exercise your voting rights and make sure the outcome is what you expect.
In the welcome in the beginning I actually just noticed that I forgot half of it. Stupid computers messing up everything. I didn't introduce myself, I didn't introduce Sander, so hello eye Gert Doering, I am chairing this. And this is Sander Stefan, my co chair, who is helping me in doing all this preparation work and chasing people and finding volunteers to come up here and present things. So, thanks Sander.
Something else that's on the first slide actually so I don't forget it is that this session is webcast, so if you want to say anything, please remember to speak into the microphones and state your name so that remote participants can hear you and can see hear and see what's going on.
Okay. Now that's enough from me. I ask Phylis to give us an overview on the current policies proposals being discussed worldwide. Usually we give her ten minutes and she has to talk very, very, very fast. This time we really have plenty of time, so Phylis take your time.
Previously I received even comments if I am imitating Curtis in my you know speaking speed. So this time I will take my time:
SPEAKER: Right, I am from the RIPE NCC policy development /STER, good evening now.
What I am going to do is I am going to cover as usual the policy update and PDP update from our region, from RIPE region and I will go on talking a bit about what's happening in other regions and the reason we do that is, we keep getting feedback that it is useful to look at other regions or keep an eye on them, because nowadays, things get more and more common sometimes, but please bear in mind this is not a full coverage of all the proposals that are all around the world. It is a selection of proposals as I see fit and relevant to each other.
Now, before we get into the policy world, I just want to make a short update on our staffing regards. We have an amattic on our board now. You see her face on the photo but if an a, if you can stand up and show your face once more. I put slightly new on board because she is been with us for a while now. This is her second meeting. You can also approach her for any policy related issues as well as me. She will be here until the end of the meeting.
Right, this is the overview. The global look or worldwide look, whichever you like to call it, I, again, divided into teams because that makes it much easier to cover certain stories, and so the teams are IPv4. Then I will cover the end tail of IPv4 pool related policy proposals. I had a hard time finding one title to categorise these, but they are about those who are dealing how we should be maybe allocating the last bits of the free IANA pool or they are about transfers and there are also some proposals starting talking about the usage of legacy space, historical assignments, historical allocation. So this does fit in there.
IPv6, well, we have a few updates from there and quite surprisingly, its own slot has a bigger slide this time. It is quite full there. I will give you some update in regards to what's happening in that area.
Now, the archived ones, Gert already went through these. The first IPv6 assignments and allocations for every end user and for every LIR, they were withdrawn straight after the Berlin meeting. Then we had the cooperative distribution of the end of the IPv4 free pool from Tony Hain and I the story about this was about basically, it was talking about again the end tail of the IANA free pool and the proposal was to, is adopting anything for IANA runs out, as soon as IANA runs out, the RIRs start going to each other, so there is, there will be one sponsoring RIR who would at the time have the biggest capacity of the address space, let's call it. And the others as they receive requests, they would go to that RIR instead of IANA because IANA wouldn't have any space by that time.
However, the logic says this would only work with at least there would be two RIRs who would be doing this practice or agreeing with that practice and three of the RIR regions, they rejected this proposal so it was abandoned there. And in LACNIC region, it was never proposed. So at the end. Tony decided he would withdraw this.
So for the accepted ones, again the global policy for the allocation of the remaining IPv4, Louis Lee covered that. I won't get into details and the 2007 01, you just heard the contractual one from Andrew, so I won't get into any more details.
Now, the current status: We have seven active proposals in discussion phase. This means we are discussing the initial bits, initial idea about those proposals, the very first minimum four weeks time is active on these proposals. And the first one, PI for IPv6, that is already in the agenda fored to, I believe, straight after me Jordie will take on with that. And ULA central, those two are kind of resumed so far because the first one especially, it had a clause as it would be active only when there would be a contractual relationship between the end user and the RIPE NCC or the LIR, there was that phrase which obviously we were busy with the other proposals, so the working group chairs decided at the time okay, let's first finalise and conclude on 2007 01, the contractual relationship proposal and then we will go back to this.
So now this will resume.
ULA central, we will have an update, hopefully be doneed to. Anycasting ENUM, we do have Anycasting assignments specific policy for the D HDs. You might be aware. (TLDs) and the proposal argues that similar needs exists for ENUM operators accordingly they should be receiving address space through the same policy. And that is the core of the idea there.
User the final /8 and use of historical IPv4 sources. I will touch on these later on again but the basic idea is when RIPE NCC is allocated with the last possible /8 from the IANA pool, how do we use that, how the policies will be affected within that block only, so nothing will change until we received the last /8 and then what we will do afterwards with that block is discussed in this proposal.
The legacy, historical resources mentions are coming into place with this 2008 07, ensuring efficient use of historical IPv4 resources. It is looking for justification of the use of the historical resources for those LIRs who come to us, the RIPE NCC, for further allocation. As you know, we have an 80% policy to oversee the blocks that the LIRs hold already, only when they can just used these resources up to 80% they will be eligible to receive another block. With this proposal, if it is accepted, the blocks that are considered as historical or legacy or ERX time, they will be, they will be in that group where the 80% will be looked for as of usage.
But, yeah, the details of this again will come in the agenda. I will leave it to Philip Smith to go through the tiny bill details.
And initial certification policy for provider aggregatable address space holders. Those who were in Berlin at the previous RIPE meeting might remember that there was a presentation about a possible proposal coming soon. Now, this proposal is that realisation of the possible proposal. We have a certification taskforce who has been working over the details of this possible service for a while now. I believe since RIPE 53, or something. And one of the aspects they were studying was the policy implications of certification and this is the output and in a way, a report to the community, so that the community can discuss certain issues around the service. It will be presented, I believe tomorrow, in Tuesday's session.
The ASPLAIN format for the registration of 4 byte ASN is part of my ASN slide but is shortly talking about using AS plane format instead of AS dot for use of 4 byte AS numbers.
Review: Just before I go into review, I want to make a little clarification about what review phase again, if I may since I have time this time. Review phase is one after discussing the initial idea about proposals we publish a draft document, a draft policy document where this initial idea is integrated into the whole of the document. Because, within the RIPE region, we document all policies in documents where they are teamed up again, we have one document for IPv4 policies, one document for IPv6. So if the policy proposal is affecting IPv4 policy either by introducing a new policy in it or changing an existing policy to be, you know, updated in that document, this is when we publish that draft document so that the community can continue on discussing the proposal while they can also review the change one to one. And the way we publish it is basically we mark the change with the original document and then the proposal, the change that proposal is bringing into.
So, this is other phase and we have two proposals that are in this phase now. One is PI assignment size which is talking about setting a minimum assignment size for PI address space. And the other one is the enabling methods for reallocation of IPv4 resources ICANN transfers proposals. I I'll talk about this as well.
Now, this is my smooth transition to the other regions and when you look at IPv4, some regions has been busy about minimum allocation size and the allocation periods. I think minimum allocation size is, speaks for itself as the title. APNIC accepted and implemented a /22 already for a while now. And in ARIN, they are having a last call for /22 again for their Caribbean portion only.
The allocation period, what I mean by that is, when an LIR or an ISPV, we use different terms among LIRs, let's say the local registry in RIPE terms, they come for further allocation or first allocation, as the RIR we foresee their possible needs for a certain amount of time. Theoretically it can be three days to three days to six months. But you don't want to allocate some space to an LIR where they will just come back used up all of it tomorrow because that doesn't scale, right. So, that's the period I am talking about. An APNIC is at the moment discussing a change for that period to be set to six months. Currently they have twelve months. And the argument is, or the rationale that has been used in this proposal is that we are coming close to some scarcity times in IPv4. So maybe, closer look up on the usage of the LIRs might be beneficial at this period. So... not my idea, their idea. Just passing the message.
Now, usage of the last blocks. Like I said, there are several things being discussed. Three regions have been active talking about this concept, and in ARIN land they have decided that they will reserve a /10 and they will make assignments for key dual stack DNS servers and for those not translators from that last block, so that is their plan on how to use the last /8 that ARIN will use within their region.
APNIC accepted those two proposals that I mentioned. They are very similar to the ones we have here so they will be presented and you will see. But they are talking about allocating the minimum allocating allocations, blocks to new LIRs and existing LIRs on the size of the minimum allocation size. And I believe a /16 to be reserved. And same topic about asking for efficiency in the usage of legacy space if the requester is a holder.
Then we have LACNIC talking about reserving a /12 from the last block. And making /22s for new SIPs and for critical infrastructure operators and they have haven't their finished their critical infrastructure so let's keep it there. This is how it looks about the usage of the last /8 plans and some acceptance from different regions.
Now the other hop to the I can, transfers: ARIN has been discussing transfers for a while now, like us. And actually in their last meeting they discussed another one. So they had two proposals in place at the same time and one is called to define them for you: Transfer proposal, the one that has been discussed for a while now and the emergency transfer proposal, which is rather new.
The transfer proposal, compared to the emergency transfer proposal, which is the new one, is quite detailed, and that has been abandoned now. So they will continue with the emergency transfer proposal.
APNIC and RIPE, as you know, we are also discussing these transfers and transfer proposals. And before I get into more detail, I want to show you a matrix which I already showed in Berlin a while back. And this is a rough comparison of the transfer proposals at the moment. And one of the things is you see two columns being empty for all of the RIRs because ARIN quite detailed previous transfer proposal was having criteria for those and now they dropped it and this is column for ARIN is now representing their new emergency transfer proposal. So that's why I kept the columns if you would rather go back and try to compare things.
But, what is common is being a member of the RIR IR. ARIN and RIPE has a criteria to the need to be justified before the transfer occurs. The minimum block size will be kept as the current size for ARIN and RIPE while APNIC is setting it already fixed in the proposal which is a /24. The end user assignments should not be sitting on the blocks, that will be transferred in RIPE region while in APNIC and in ARIN, I don't see any mention of that. In RIPE it is only binding or talking about transfers among LIRs and for their provided aggregatable address space. While APNIC and ARIN, they do not make any distinction about the type of address space. It can be PI. It can be PA, as I can read it.
The other criteria is about on the transferring organisation for APNIC that they can not receive any new block from APNIC from the RIR within the next 24 months, while the other RIRs don't have that criteria. And the other important thing, like I said, is on our side, we ask, the proposal asks for the recipient organisation that they cannot transfer the block that they received already as a transfer within the next 24 months, and the argument was for that was to avoid speculation. We don't see that in the other region in our proposals.
And the other significant difference between RIPE proposal and the others is that the RIPE proposal covers the permanent and non permanent transfers, if you like to call them like that. With permanent it's basically you transfer the block and the holdership goes to the other LIR. While with the non permanent, it is letting another organisation use the block for a while, but the response LIR, main responsible lies still on the transferring organisation.
Now, for the IP version 6, yeah, IPv6 PI has been a top topic for a while now and in all other regions, there is a policy for that already. After LACNIC also accepted a/48 for a minimum. And we, in RIPE land, we will be discussing this.
Now, the overflowed ASN slide. Three things, three updates:
APNIC has reached consensus in their last meeting for reservations for AS numbers for the documentational reasons and although that happened, they reached consensus today, Randy has sent an announcement in their mailing list, in the APNIC mailing policy mailing list that they will do nothing about this for the time being, because they are aware this proposal prompted and Internet draft in ITF and they will wait for that conversation to be concluded. This is what the announcement says.
And the same goefs for the AS plane versus AS dot proposal actually. We have it under discussion, it will be presented here while APNIC also, although they have reached consensus in their last meet, same similar announcement applies for these too. They will wait for the Internet draft to be published and concluded for the next two months.
Then we have the change for 2 bit AS assignments time line. This is rather different. You might be aware we have a time line among RIRs and that polley has passed sometime ago, by 1th, 20094 byte ASNs will be assigned by default, unless the 2 byte ASN is requested, specifically requested. Among these time lines, APNIC also passed one more iteration, one more edition so that which 1st July, 2009, if the holder of the 32 bit AS number can demonstrate that it is unsuitable, then it can be they will be eligible to receive 16 bit or 2 byte ASN number.
Now, like I said, this is a summary for you to give you a preview about what's happening here, what is about to come because all the policy proposals that are mentioned for RIPE are going to be in the agenda of the Address Policy Working Group from now on until I am so confused too Wednesday morning. But the others, they are a selection and if you want to know more about them or you want to go through their details, these are the links just for your information.
And if you don't have any questions, I guess I can leave it to Gert and Sander.
(Applause)
Gert: The applause was too early. I wanted to say thank you Phyllis first. Thanks for the applause anyway.
Thanks for taking your time and really detailing this. I will now go back to my slides.
That's just a brief repetition on what Phyllis has already said anyway. This is the new proposals that have entered formal proposal stages in RIPE since last meeting. There is one not yet completely formal in there that will be discussed tomorrow. But, depending on the feedback, it might enter formal policy proposals stages so it's on the list.
That's the Anycasting prefixes for ENUM. The plan was to have a short today,. Ian couldn't come but we have found a column volunteer.
Tomorrow, we will have a short presentation and the problem statement by and re from the RIPE NCC about IPv6 address space for RIPE meetings and discussing.
Then we have two proposals from Philip Smith about the usage of the final /8 and the efficient use of historical IPv4 is also tomorrow. They are likely to take place at 11.
Then we have the certification policy we will, which is planned to take place at about ten minutes to twelve. And the ASPLAIN format change presented by another volunteer because James couldn't come either.
Let's get right away to the discussions. The first two bullets are sort of something you should know, but I put them there to make it very clearly visible again and remind those that have forgotten about it or have doubts on how the thing works. The address policy meeting at RIPE meetings is not the place where decisions on policy is made. This is important because it means that if you don't have funds to travel to RIPE meetings, or you just don't have the time to travel to RIPE meetings, it doesn't mean you are excluded from participating in the policy process.
On the meetings we discuss things because it's, well just faster to get more opinions on given policy proposals. But the final decision and the final sort of consensus process will always be done on the address policy mailing list. So if you are interested in policy, please subscribe to the mailing list. There is about 2,000 subscribers currently on the list, so I know that the participation is much higher than just those of you sitting in the room. On the other hand, thank you all for coming anyway, because this really helps getting more input.
Technically, when you want to say something, please remember to use the microphones so that the transcribers have an easier job and that remote participants can hear you, please speak your name and if you think it's relevant, speak your affiliation and that's pretty much it.
If you are remotely participating, you can send back comments and questions by Jabber, and the Jabber scribe will then relay it to us.
So, now it's the 2008 05: Anycasting tier 1 tier 0 ENUM. And Neil has volunteered, more or less, voluntarily, to proxy the original presentation and I think it's since I am acting for somebody from, eye real affiliation isn't relevant so I won't mention it.
This policy, 2008 05 is in discussion phase and these slides help you to, help to remind you what it's about and put it in its context and I am sure the discussion will continue on the mailing list.
Some words of introduction on NONINET. It's the UK CC L D registry. It runs the UK DNS servers without Anycast at the moment, but as I understand, that's planned. (NONINET) it also runs the plus 44 ENUM registry and is planning to move the 4.4.E 164.arp aDNS server cloud to implement as an Anycast cloud.
And today the phone number, the phone number part of the DNS name space under E 164 arpa is in many ways structurally similar to CC D L name space because it's aligned along countries or geographical areas and so the kind of customer or end user requirements that might be expected of it or can be expected to be similar. And that's really the justification for this proposal.
Today, IPv4, Anycast is underpinned by RIPE document 424 and for IPv6 the correspondence document is 421. And there is nothing in there for the ENUM part of the DNS tree. And the intent of this proposal is to fill that gap.
And this slide is a little bit dense, but I think it was a good choice from the author to put it all in one place. It's probably something that you need to read slowly, not necessarily while I am standing here, but the key points are that the new part is that here, not just ccTLDs, but also well not just ccTLD and gTLDs at present but also tier 0 /1 ENUM registry operation should be facilitated and accommodated in the same way by having Anycast available to them.
And then at the bottom of the slide there is a glossary of some ENUM related terms. You probably know that tier 0 ENUM is run by the RIPE NCC. That it sits in the same space the same significant position as, for example, in a.arp aand the tier 1 operators are the national or in some cases the geographical region where the country code spans other countries.
I think that's about all I have to say. I'd leave that slide rather than the invitation to questions and comments because you may prefer to see that one rather than one that contains no information. I'll try to answer any questions, if there are any, but I suspect that the author of this presentation is probably in contact by Jabber and may be in a better position to answer those questions than I am. That's it.
CHAIR: Thanks Neil, for coming forward and helping out with this. Brett is indeed in the Jabber channel, so specific questions can be answered by the original author.
Okay. Now, basically the question goes to the audience. Do you think this is a useful exercise? Do you have worries that this is going to, well make the routing table explode? That brings yet another special case prefix? Please stop reading your e mail otherwise we will have to turn off the network. I see Peter Koch from DE NIC coming up and, well you are the first one, please go ahead.
AUDIENCE SPEAKER: You asked for it. Peter Koch, DE NIC, and for full disclosure we have received Anycast prefixes under the current policy for operating the DE top level domain and we night actually benefit from, well our customers of course might benefit from that policy proposal being approved, because we also run the ENUM tier 1 registry for plus 49 for Germany.
That said, and more or less independent of that, I think it's a useful proposal. The ENUM tier 1 is, when it comes to infrastructure, is very much comparable to a TLD, that's probably what Neil said. However, and I am not sure we can get condensed on that one here, I am a bit unhappy about the wording and again I was kind of involved in phrasing the exact terms about the IANA administrative procedures and so on and so forth when it came to the original proposal or the original change, and I think from a DNS perspective, and I am sorry I can't get away from that, it makes really sense to phrase that way. So, I would fully support the spirit of the proposal, but I'd suggest that the wording needs to be improved to actually make sense from a technical perspective.
CHAIR: So this seems to be the proposed new wording anyway. So do you go along with that one or do you have specific other changes that
AUDIENCE SPEAKER: No. The part, the phrase is in there that don't make too much sense from my point of view are: Referencing the IANA procedures for the route zone... in the context of the ENUM tier 1 delegations" because some rules and some preconditions that do apply to TLDs don't apply to ENUM. That's deep DNS stuff I am not going to bore the audience with here.
CHAIR: So that specific wording in the proposed policy text then. May I ask you to sort of send the DNS related worries to the proposer and maybe the list so that we have, in writing, which is, which needs changing and so...
AUDIENCE SPEAKER: Would you allow another response then, yes?
CHAIR: Well...
Thanks.
AUDIENCE SPEAKER: It's Marco. Two comments here. Again possibly Brett gave a rough guesstimate of how many organisations would apply to this definition. And the second question is: What will happen to organisations who will basically be you see a lot of people write about the ccTLD and the ENUM delegation, it's happened in The Netherlands, it seems to happen in Germany, will they apply for it too? Any blogs or will they have to share any /TKPWERS blog for that
Answer: I am doing the Jabber monitoring. And I got a comment from Brett who says I tried to write the new policy by not changing the original wording as much as possible and minimising the resulting discussion. I have lost sound now, so I can't hear the comments and questions." He seems to have some band width problems.
CHAIR: Okay, I think that was a comment to Peter actually about the change of words, but as Brett is willing to adjust whatever is necessary to make this more well, a more well rounded document.
Regarding Marco, I would /SREUG err I guess that we will see, at the maximum, the number of countries plus one. So this is something that's definitely not going to make my routers explode. Well maybe a few more or less okay, please go ahead...
AUDIENCE SPEAKER: On the question of Marco, will registries that operate both a country code registry and a registry get to any guard clouds? I would say I would apply for six actually, because the issue that I currently have is that for my registry, you can only apply for one Anycast cloud and I don't think that's redundant enough. I want to be able to run more than Anycast cloud.
CHAIR: I think that was actually a targeting the policy as it is now for the DNS for the TLD Anycast as is says you can get one per organisation. But not per TLD. I would prefer to not sidetrack this proposal into whatever might need changing, but you are certainly welcome to sort of bring up that topic on the AP WG mailing list. I think you next and then we'll take Jabber again.
Audit audit we also support that proposal. Maybe what I am missing is the v6 policy for the ENUM, same one. Actually, I also speak to some people from ARIN region and they received six PIs for each domain they had. But let's leave it open.
CHAIR: I think I'll take Jabber next because that might go
SPEAKER: Well I have comments from Brett, that's why I am standing here. He replies and it's about the previous question I think? Yes.
"I would say those who have applied for the ccTLD policy would likely apply and they would require two blocks as ENUM and ccTLD are usually separate policy politically in and out."
CHAIR: Okay, so that basically answers Marco's questions about how many blocks an organisation would get that have both roles. Jim Reid please.
AUDIENCE SPEAKER: I really have a question, it's more of one to do with detail and definition of the tier 1 ENUM operator. What do we mean by the organisation as being delegated the responsibility of operating the name server? Because the way in which a lot of ENUM delegations are managed, there is an organisation or an entity that's responsible for the delegation of the country code. Typically that would be the regulator for the country concerned. It's not always. Take, for example, the UK, it's done by the Government and the Government is handed that off to an independent not for profit company and that company then contracts with somebody to provide services for the registry and DNS as part of that. So are we talking here about taking for example the UK one as a specific case, but as part of a general question is:
Does this address space go to whoever is running the main servers for that countryed to or does the space go to the organisation responsible for the delegation and then they would have potentially the ability to choose their Anycast provider and then have that routed that space part of an existing Anycast operation and they would not have to renumber if they switched Anycast providers? So who is this space for? Is it for the guys running the registry or for the guys responsible for the delegation?
CHAIR: Well, I hope that audio is working for Brett because I just plainly cannot answer that. That's ENUM proposal thinking.
AUDIENCE SPEAKER: I am quite happy with the broad idea of having space at the time aside for the tier 1 operator for some definition of tier 1 operator but I think we have to be clear, does this space go to the people providing the registry service or the people who are actually responsible for the delegation, they are not necessarily the same thing.
CHAIR: Okay. I think Neil has a response to that, do you?
SPEAKER: Some further comment on what Jim was saying and this is Neil O'Reilly again, and I am not acting any more as its proxy for the author or as the chair of the ENUM working group or even on behalf of the university that employs me. I am just a random Irishman.
In my country, the statutory responsibility for both the ENUM tree and the country code TLD lies with the telecoms regulator and I can imagine that the telecoms regulator or people, whatever the authority should be in that position, and Jim has mentioned in the case of plus 44 ENUM will not see the usefulness of the organisation who is contracted to do the work having to hand back the Anycast allocation in order for a new one to be handed out to a successor organisation should the authority change the contract. That would seem to be silly.
So, my suggestion at this stage for the purposes of moving this policy forward is that, if we have or as soon as we have consensus on the list that it is a useful thing to do, we should move forward. If we need further policy development to refine what our definition is of who is in charge, for want of a better phrase, we can do that as a refinement or as an additional policy and likewise F we decide that it should be a number of 24s or a single 24, we needn't get hung up on that for now.
CHAIR: Okay. Thank you for input and clarification.
AUDIENCE SPEAKER: I'd like to go on saying in another way, I mean, there is a quantitative issue in this statement, either for ccTLDs, Anycast or even for ENUM, suppose there are countries who deal with many country codes an telephony numbers, so I mean on the principle, I am in favour of ENUM being treated equally as ccTLD Anycast, if this is a need for ENUM community. For instance, I am not in a position, France is not running operational ENUM, so I mean, if it is needed, I am in favour of it being equally treated. Yet, there is, I think, a fundamental problem to be dealt clearly with the quantity. If we are running many clouds of Anycast, and that's the case for many ccTLDs, I am not advocating, I am not I mean, the spokesman for them, but this is something we need in France and we are going to run in house Anycast. So it is important to provide for how many? Actually, the second block or the third block is as easy to get as its first. Supposing that we can get more than one, so I think that one day or another, we have to state whether there is only one block for ENUM, only one block for Anycast or if there are more than one, what are the rules and what are the justifications to get them?
CHAIR: Okay. So what I am hearing is that we might need to re open the discussion about DNS for TLDs as two persons have voiced that, to redefine the criteria on what is, if you run 3, or 4, or 5 TLDs? This is a bit outside the scope of the ENUM discussion, so let's fix this and then maybe re open the other one.
I see Curtis standing in line and Jabber, so I think
SPEAKER: I have an answer from Brett regarding Jim Reid's question, if I may?
CHAIR: Please.
SPEAKER: He says. This is an answer to Jim Reid's question on who receives the allocation.
"I would say the registry but I wouldn't have any problem with being a Government sponsored organisation."
CHAIR: Okay. So what I am hearing from that is that we really need to work on the wording of the proposal so that it is really clear what this is who is eligible to get the prefix and who stands operating things. So more work needs to go into the formulation. Please, Curtis.
AUDIENCE SPEAKER: If I remember history correctly, and I might not, but the Anycasting policy for TLDs was created because the RIPE community thought that TLD operators constituted a critical part of the infrastructure and therefore, were on special standards as opposed to everybody else who is not special and critical.
I can sort of buy into the argument that an ENUM TLD might be roughly equivalent to critical maybe, if anyone actually employed ENUM, but the discussion with Jim, he asked the question originally that when we created a policy we were supposed to give the prefixes to the TLD operator, whoever was currently operating a TLD so they could give the prefix to whoever bought the service of Anycast from.
The argument here if I understand correctly is that the ENUM operator might not necessarily want to buy service from the same or want to apply different policy and therefore needs to different prefix, maybe. But if it's the same, why would they need two prefixes? I think that it policy simply is very poorly written and needs to be rewritten. I think you have to do a lot more thinking behind this. I don't think the intention here is should get two prefixes to launch on the same service for the same operator, for example. That seems to me completely a waste. Given the argument from whoever it was, Peter or somebody, who said he wanted five or six prefixes. This is a very good way of doing a run around the policy, the way it was intended and I just think it's a very poorly written policy. I think it should be rewritten and come back.
CHAIR: Okay. Some more food for thought. Thank you. Peter then Marco.
AUDIENCE SPEAKER: I don't agree it's a poorly written policy. I think it is a straightforward extension of the policy that we applied to ccTLDs or TLDs in general at that time. My recollection is actually what Curtis just said. The allocation or assignment in that case should go to the TLD, not to the technical operator, so to the TLD operator but not necessarily directly to the DNS name service provider so the operator could choose who to hand it to. That spirit should be maintained when extending the policy here. It might need some more wording but I read it the way it's written.
For reasons to and of course I also want six prefixes and so on, but I also want a pony, but not by this policy. So we please separate this issue and I appreciate that the chairs are having a very clear, making a very clear distinction here so we should just focus on the ENUM stuff.
There might be reasons to choose either different operators or even give the same operator different prefixes because of I don't know what, regulatory requirements or operational requirements, that the Anycast cloud be set up differently for both the ENUM tier 1 registry and TLD registry or TLD zone in question, and with the same prefix, we have to share fate and we can't just provide a single service in a single location but we would have to provide both or all services in the same locations.
CHAIR: There might even be regulatory things that prohibit putting up ENUM service in places where you have a DNS server or something. So I could see reasons why there might be two clouds.
AUDIENCE SPEAKER: Marco again. I partially agrees with /PUR /TEUS and I am responding to your comment on maybe pushing this forward and then having a discussion on how many blocks an organisation should have. I think we should keep in mind that if we do that, we basically create a temporary policy and we are not actually making it a level playing field because those of guys running it as of now can immediately apply tore and from the time for instance fans is ready for ENUM we change policy again. So if we already know there is going to be some discussion and change coming, we shouldn't put this forward until we have covered the whole work area. And not just make a temporary solution by now changing into ENUM and then having a discussion on how many prefixes. Just put it into one policy proposal and then take it back into the discussion.
CHAIR: Okay. Jim, then Jabber. Then Neil, then I am closing the line actually.
AUDIENCE SPEAKER: There is something seriously wrong here. I am violently disagreeing with Curtis and violently agreeing with Peter.
I don't think this policy is seriously broken at all. I think a little bit of finessing and wordsmithing and it will be perfectly fine. I think the main sticking point is the definition ENUM operator. If I think delete the words "Responsible for operating the name server" I think it should be "Delegating the responsibility for a specific geographic region or the tier 0 ENUM operator" I think that would clarify the definition and sort this problem properly.
The points that Peter made are quite valid. The ENUM stuff is critical infrastructure is in some ways in some respects rather different from ccTLD infrastructure. Because it could be bought by different contracts. Different levels of service agreements. Different duration of those contracts. For example, many countries there is no agreement between the governments or the regulator and the ccTLD registry. That tends not to happen with ENUM delegations. The regulator has some involvement in that and usually has contracts for a fixed period.
So, in that case, you may have a scenario where the current incumbent provider registry services for an ENUM delegation might have that taken away from them let's say in five years or ten years' time and at that point the addressing resources that have been assigned for ENUM delegations need to be shifted somewhere else. So, in that case it probably needs to sit with the entity responsible for the delegation rather than the entity providing the registration services under that delegation. (Registration)
CHAIR: Jabber please. Neil please.
AUDIENCE SPEAKER: I am just reading this text a little more carefully again and realising that I have missed one or two words when I was looking at it in preparation for talking about it. But I am speaking now again as a random Irishman who hopes he can contribute a little to this discussion.
At the moment, the policy as drafted and as proposed doesn't offer more than a single dedicated /24. I am okay. It may need to be more precise about to whom that's offered and Jim's comments are sensible, at least to my mind. But it looks to me as if the if we want to make this a much better worded document, we risk creating confusion by using different language in this document from the language that we use in the companion documents and that will, at some stage in perhaps the not too distant future, suggest to people that there was a different intent, and it seems to me that the intent of this proposal is simply to accommodate certain parts of the ENUM name service which are somehow recognised as being more or less equivalent in significance to the TLD name service clouds in the same kind of way. And I think we shouldn't try to achieve a bigger policy step than that one in the dealing with this document. If we need to tie down some of the terminology a little bit, let's do that, but let's not worry about how many blocks it is. It says a single block. Let's understand it as saying a single block. And if some country finds that this isn't good enough and can't fit the architecture that they need to deliver the services that they require, let them come back and propose a new policy in due course, but let's not let's not fall into the usual trap of which some of you will know, you know, let not try to make something perfect when we can do something that's good enough.
CHAIR: Thank you, actually that would have been a very nice closing word but I see can you remember /TEUR there.
SPEAKER: Can I have one second from Brett? Brett /KWAOEUTS: "Neil would put it exactly as I would."
AUDIENCE SPEAKER: The fact I have a line of ccTLD and TLD and ENUM operators thinks this policy might need only a minor word change. There are other constituents here. My worry first of the of a I thought it was a cut and paste error but I think it might be correct. If the name server says the ccTLD... or operator or administrator can get the..." I had to go back to Neil and ask is one dedicated /24, to whom? Is it to the who? What if they follow both rules. Who is getting the prefixes and how many prefixes it's getting? I don't know.
CHAIR: That certainly needs clarification.
AUDIENCE SPEAKER: That's what I thought.
CHAIR: Okay. Quick.
AUDIENCE SPEAKER: Seven words: I guess this is for the list.
CHAIR: That's exactly what I was proposing now. I seem to hear support and detail work that's needed. So I ask you to work with Brett on the list to sort out the details. Sort out the uncertainties and yes, don't make it the perfect world of solving proposal. Keep it simple and get it through.
Thanks so far. Now, it's Jordie.
Actually we have two policy proposals from Jordie who has been in the unlucky situation of the working group chair saying okay, your policy proposals with suspended for now, we need to sort out other stuff first. These are open proposals since 2006. And since the IPv6 PI proposal at that time was very controversial and especially the part about the contracts was completely open, we decided to postpone it until we have the contract proposal 2007 01 sorted out. That has been done now so we have a contractual framework for end user assignments and then we can finally restart this one.
SPEAKER: Okay. What I have done in just I think it's for slides is trying to capture the last snapshot of the discussions in the mailing list. Assuming that we are going on, and I believe that's the case, that it's accepted already the end user contract, right. I have already drafted a new version for the policy proposal. If what I heard from the room during my presentation, it's that we are okay with this, I can even send the draft to the mailing list in parallel to the process so that people can read it and we can have more time to discuss during the rest of the week or whatever.
So, basically the idea of this proposal is the same when we started in 2006, was to look for a solution for organisations that need IPv6 PI, either for multihoming, which is the most common case,, but there may be other reasons behind that and we keep that open, so there is we don't want to close it only for multihoming or we don't want to, let's say, declare openly what may be the other reasons because we will enter in an endless discussion and too many possibilities that we will not be able to reach a consensus.
So, if we accept the end user contract, then my view, and I believe it's what I have been reading in the mailing list, is that the qualification for the IPv6 providing independent should be to have a contract, either a sponsoring LIR or a contract with the RIPE NCC and that's already detailed in the 2007 01 policy proposal for the end user contract.
There is one more detail that I believe it's already also described in 2007 01 which is the the PI assignment cannot be further assigned to further organisations. And my only open question here, and actually I believe it's the only question I can ask the people here is:
Do we believe there is any additional need for any other qualification? I believe not, but that's my personal opinion, my personal view. Let's keep going and after the slides we can have a discussion on that.
Regarding the assignment size, I think the conclusion was to go for a /48; that was what we heard in the mailing list and that's what we also have in most of the other regions. What we see also in some of the regions, not all of them have the same situation, is that if a larger block is justified in the request, it can be assigned. But by default, it will be a /48.
Subsequent assignments, if justified, again, whenever possible from an adjacent block, they have to have super block for the assignment of those IPv6 PI prefixes so SIPs can easily adjust filtering and so on. Say for example, all the /48s belonging to this super block are the PIs from RIPE.
And that's it, so short. I think the only open question basically from my perspective is: If we want to have an additional qualifier for the people requesting IPv6 PI or if that's enough what we have right now?
CHAIR: Okay. Thank you very much for bearing with me for delaying this for so long and for coming up and presenting this again and again. When this came up first, there was no experience with PI in the other region, so everybody here was jumping up and down saying PI is so evil and the world will end.
In the meantime, the other four regions have accepted a PI policy and have started handing out PI address space and the world has not yet come to an end. Even though I don't personally agree with all the PI stuff I see in the routing table, still the routing cable has not yet exploded and had a hasn't been a Land Rush either. That's important either, it's not like there has been 50,000 PIs given out in other regions. It's more like a couple of hundred, which is quite a significant amount, but it's not multi tens of thousands. So what we sort of need to agree is do we want IPv6 PI space? That's basically the first question. If the answer to that is yes, then the second question is: What are the rules?
I seem to hear from various organisations that PI space is something they want to have. The other regions seem to agree that it is so. I am not usually going for everybody. So let's do it as well, you bits a point of reference that there seems to be some sort of consensus. Please... your comments...
AUDIENCE SPEAKER: Marco: I just want to voice my support for this one. I think we got /WOD IPv6 PI but what I do want to get some consideration is the fact that you suggest it in blocks, because that means we are going to reserve space and reserve space for a lot of organisations who will need it, because for the way I read it is we are going to do the same as with PA allocations, you get to 32 and you can get grow to 31 if needed. If we do that with 48, where is the limit? Do we reserve the 32? Do we reserve the 44? How much space do we reserve per PI assignment and how long is this reservation held?
CHAIR: Sorry, let me answer that: This is actually I think again an implementation detail. We can at this point in time, recommend to the RIPE NCC to sort of take care of, if this organisation is going to come back with any categoryings and they know how to do binary job and big block and spit it into half and make optimum use of the block while at the same time reserving space for growth, I think we want to agree on the fundamentals first and then go into the detailed mechanics.
AUDIENCE SPEAKER: I would exclusively address your first question: Do we need it?
I tend to be quite pragmatic. I personally hate PI space, whether it is in IPv6 or IPv4. This the on the principle. But we have been waiting for ages for the alternative in IPv6 or whatever and it's not yet there. So, to be pragmatic, there are companies which are right now and which use IPv4 PI space to do that. If they want to do the same thing in IPv6, in the RIPE region, they simply cannot. So, I think the need is there. As far as multihoming is one among others rationales for IPv6 PI. So, yeah, maybe for operators it's not a welcome thing, but I mean for companies which are already multihoming, this is a real need. So I am actually echoing that APNIC for instance is /HR RS doing homing in IPv4 and we have already IPv4 legacy space and we don't have IPv6 PI. So we need that.
CHAIR: Okay. Thank you.
AUDIENCE SPEAKER: This is Martin Leavy from Hurricane Electric. We do operate an IPv6 network. The thing about PI space is there is a couple of important points to point out here.
I am just trying to count this while I look at it here. ARIN has already got 223 assignments of /48 space. APNIC has got 52. AfriNIC has 7. LACNIC 8. And there is one in RIPE at the moment. If you go with PI space as an operator of a network, I can't tell where that announcement is coming from. There is no colouring of the route inside the hardware that says which registry it comes from. Therefore, this is a fait accompli. As an operator I have to accept 48 its, so you might as well as take the operator argument about this off the table. That was a conversation a long time ago. CAT is out of the bag, done, finished, end of story. So that's the first comment.
The second comment is: Do this just to get a certain /48 out of Sweden out of the routing table, and if you know what it's there. It's the first one in the routing table, it may get filtered, but, again, just get this over with, everybody else has done it, just do it.
CHAIR: Sorry, I didn't need to laugh about because I know what he is talking about. Somebody is voicing their rebellion against or policies. Lorenzo.
AUDIENCE SPEAKER: Regarding that /48 I think transit should be filtering out stuff that's not in 2000 /3.
AUDIENCE SPEAKER: It's filtering. It's done.
We see it in a lot of places. We do operate the IPv6 network as well. But we don't need a /4 because we have a /32, but I would say, would I tend to agree with moss an's comment,. Considering the effect on the pace of IPv6 deployment caused by the absence of a truly workable multihoming solution. By truly workable means equivalent to v4 which means yes /TPAEU and Shim6 can sort of take care of that but is also means balancing and traffic engineering. So when you go up to any sort of business that requires Internet connectivity for mission critical applications, they are going to say, why should I deploy a IPv6 if I can't even keep my network up by connecting two different providers. We should consider the effects on adoption. I personally see this as blocking adoption in a lot of cases.
CHAIR: Okay. Thank you. David.
AUDIENCE SPEAKER: I am actually concerned about principles of fairness and I have said this before. If you are going to allocate address space to PI address space to a company of a certain size and if the company is actually way bigger than many of the SIPs that were given /32s to. I think there is a fairness principle problem there.
And if you have policies in place that allow that kind of stuff to happen, I mean that's basically asking for regulators to come in, for other people to come in to say we don't do a good job in managing those resources. So, I believe actually we have a big problem here on our hands and I think it's either we should actually lower, give less address space to ISPs that are simply too small, or those companies should all get a /32. I think what we are doing is getting into a really weird situation where there is two classes of IP end users and they might have exactly the same needs there, the same number of people behind their networks and I think that's a serious problem.
Another issue, that's involved with that as well is the principle and the idea behind the /32 was that the amount that was enough for most people to not come back for a long while to the registry, and I think we have to be careful that we don't depart from that principle, but if you actually do want to depart from it, we should depart from that for everybody, so including the ISPs.
AUDIENCE SPEAKER: Can I say something? David, I think with the existing IPv6 policy, this is no longer the case because most of the organisations that may need more space can already request from a standard PA because they are considered, they can be considered a regular LIR. For example, a big bank having many branches and so on. And on the other side, in this proposal, what I am suggesting is minimum /48 but if you justify for more, you get it. So I don't really think there is a kind of two classes of entities or at least that's not intended in the proposal and I believe I am avoiding it with the current wording.
CHAIR: What I have seen in the US is that big companies can get actually well they have been assigned up to /43s, to the argument a big company needs more addresses seems to work and I think the NCC can then look at the policies that, at the procedures that the host masters in other regions deploy to decide on size.
AUDIENCE SPEAKER: The thing that you saw in ARIN's case for example, is that especially in the early days, big companies have to show that they are actually like an ISP, so they have to kind of put themselves as if they are like that.
CHAIR: It's a fairly recent assignment and it has been in Australia and in the US, so this is not like a Stone Age case. It's a recent assignment.
Specifically, I think as a matter of sort of classifying addresses, we do have a difference between ISPs and companies and that's ISPs are supposed to give 48 size chunks to end users, while the 48 itself by definition is supposed to be large enough for most companies so I am a bit wondering what to do with David's comment. Well we definitely need to take it to the list to continue the discussion and work out whether this is something that we really need to change, like going to 32 as it was in the beginning, or whether we can check with the other regions, whether they have had any issues with the regulators. Because, well, the same argument could hold for all four regions and they all give ISPs a 32 and PI holders a 48 or bigger if warranted. Moss an and then we go to the next topic.
AUDIENCE SPEAKER: Please, let me just try to simplify this issue as far as I can see. You may have a small company or a medium company or a large company. I don't think that fairness issue is raised for large companies. They have enough money to buy their LIR ticket in an RIR and that's the case already for IPv4.
As for medium or small sized companies, yes, there may be a fairness question if this medium companies come again and ask for yet another /48 for PI. But does experience so far has shown any problem of fairness in ARIN region or in APNIC or in AfriNIC region where PI policy is already implemented? So that's I mean a simplification of the thing. But maybe there are much more difficult cases.
CHAIR: Okay. Thanks. I think the way to go forward is to, well, take this discussion into account. Draft a new wording of the formal proposal, circulate it to the list. Of course we do it on the list, and then see what what we will be able to agree on.
SPEAKER: I will send the draft I already have which is consistent with the slides to the mailing list and formally send also to the policy chairs and let's start the discussion again. Fully, we don't have so much discussion because it seems that more or less everything is clear right now, but you never know.
CHAIR: Okay. On the agenda, I had another proposal first, then you again. I think you have your slides on there anyway, so maybe we can just short cut here.
SPEAKER: We have been discussing, I don't have the slides so that's easy.
We have been discussing for, I don't know, three or four meetings time, the question about the ULA central, we decided to halt it down until there is movement on that in IETF and it has been in stack for almost 18 months so I think the right thing to do right now is to withdraw that proposal and we will see if after the provide the independent, there is still a need or if there is some change in ITF process and I can resume it if necessary. Okay.
CHAIR: Okay. Just to repeat it in case it wasn't clear. It was a different proposal actually, proposing that RIPE NCC should set up a registry for the ULA addresses. That's unique local addresses, with a central registry, and we cannot do this without the ITF agreeing that ULAs are a good thing and they don't agree on anything, so we have stalled it waiting for the ITF. The ITF is not going forward. We have discussed this and I think withdrawing is the way to go forward for now.
Unless somebody objects and says, oh, no, ULA central is a cool thing, it will happen next month and we really need to have this? But I don't see anybody.
So ULA central will end up on the list of withdrawn proposals next time. Thanks Jordie for coming up.
This is an old proposal actually, 2006 05, which has also been stalled because we sort of decided to first get sort, get all the contract issue sorted out and then re enter the discussion: Who can receive what size of what?
The author of this proposal is Philip landing a/HRUPBD. It's formally in review phase and the thing about this proposal is that it's touching routing reasons, which we have always been sort of careful about. He says that, basically, when an organisation in IPv4 this is an IPv4 proposal, sorry for not making this more clear so far when an organisation in IPv4 wants to multihome and they have five PCs, they can go to RIPE and say to the RIPE NCC and say "We have five PCs and we need a PI address block for that" then they will get a /29 and if they haggle they will get a /28. They take that /28 go to their providers and say please route this for me globally and currently everything that's not a /24 or bigger will just not work. So the proposal is well the current practice is people are aware of this, so they lie to the RIPE NCC and tell them, oh well I have 200 machines and next here I have 220 so the NCC assigns a /24. This is sort of you don't talk about it but this is the usual work around which is ugly. We shouldn't have well maybe we shouldn't have policies that lead to impractical results.
So this is why this proposal came up, that if somebody applying for PI space says "We need this for multihoming purposes, or for routing reasons" then the minimum allocation size would automatically be a /24. This is not uncritical because, well, what happens if next year one big provider starts to filter out all 24s, because they say this is all garbage, we only accept 23s? Also, traditionally the Address Policy Working Group has always said, well we are considered with managing addresses, we are not talking about routing. That's the routing working group, go away. Still it's we need to do a decision on that and we have 15 minutes left, so I welcome your input.
I am not proposing this, I am not against T I am just presenting it because the proposer cannot be here. He is not on Jabber unfortunately.
AUDIENCE SPEAKER: So, traditionally RIPE sorry, the RIPE NCC has never guaranteed routability for any address space ever assigned to anyone.
CHAIR: Yeah.
AUDIENCE SPEAKER: Now we are arguing you start handing out you just create a policy where the RIPE NCC is forced to make the judgement whether this person needs plausible routability or not. I don't think that's a really good idea to be honest. We had this discussion before, two years ago, something like that, when we asked Leo Bennett from RIPE NCC to produce documentation on how many requests he got. I think it was a trickle, very few if I remember correctly. I don't really see what problem this solves. I mean...
CHAIR: Well the problem that it solves is that people that want to be honest about their needs can get a /24 without having more than 120 machines.
AUDIENCE SPEAKER: If you assume that you and me are alone in the bore and the other people aren't here, would I say that if we are here to make policies that don't make people lie, we really have quite a few policies, but I never said that.
CHAIR: This is a touchy issue. I am aware.
AUDIENCE SPEAKER: I understand why it's trying to get this. Several there is probably a handful of people who need these addresses but most people have dealt with this one way or the other in the past. And we are now putting in what I think is pretty unreasonable burden on the RIPE NCC to make this judgement call without giving them any data or reasoning more than they should have to deserve this space is routable. They can't say this space is routable or not. They don't know. That's true for a lot of prefixes. As you say this is a game where the carrier necessary /24. The other question is this say plied retrospectively? All the people who didn't get /24s, can they come up.
Tonnes of issues have come up here. We have been through it and I do relevant eyes if you say now no, we'll come back here in two years again, but...
CHAIR: I want to comment on one thing specifically that the two year delay in that case was sort of because we were waiting for 2007 01. So this proposal is two years old. I hope it will not come back if two years again. But this time it's sort of my fault. Steering the process. But I have heard your input and, yeah... thanks.
AUDIENCE SPEAKER: Well, what lifetime does this particular proposal actually have? Is it more than three years? And, well, okay... will things well okay, will actually fixing the /24 boundary in a policy like this looks actually like really misguided thing because, well, okay, I am sure we will be living in a time of unpleasant surprises in three years time and the question of keeping by the /24 for the few happy guys who got their PI space under this policy, well, okay, that's probably going to be very irrelevant anyway. So, I think just drop it. Keep things like they are. Thing will be changing in much larger ways. And it's going to be much more unpleasant than this.
CHAIR: Okay. Thanks for the very clear words. Marco.
AUDIENCE SPEAKER: We are in operation of building filters, make sure if you push this forward, all /24s come from a well known aggregate so I can actually put filter my whole table on 22 and only allow these 24s to go through and not just tell me to basically only allow 24 and make it a well known /16 or whatever and I can adjust the rest of my filter.
CHAIR: Okay. So if I understand you right, your statement that you don't agree or disagree with the proposal but if the proposal comes into place
AUDIENCE SPEAKER: I disagree with the proposal, but if somebody decides to put it forward, please make sure there are like this well known swamp /16 where other /24s live in and we can adjust our filters accordingly.
CHAIR: So, again, a voice of disagreement, but if it goes through, make sure it's properly tacked as such.
AUDIENCE SPEAKER: Actually, I don't support this proposal because I don't think it will achieve what it is intended for. So my understanding is that the main reason for having this proposal in the first place is to allow this PI address space to be routed on the Internet. And my understanding is that this will not be achieved even if we assign /24s. So, the RIPE NCC will not be able to guarantee routability by assigning /24s, so I don't think there is need for this proposal.
CHAIR: Okay. Thanks so far. I think we have heard four voices that are pretty clear, all of them, and we don't have very much support for the proposal, but it's more like, this is not going to work. We shouldn't encourage it, we cannot promise anything anyway, so this is just missing the mark.
Do we have anybody else who well, thinks that we really should go forward with that, maybe phrase it that way? Otherwise, we will just send a note to the proposer and say that there has not been much support on the mailing list. There has not been much support in the meeting, so please reconsider either rewriting it or withdrawing it. Of course, we will circulate it on the mailing list before that, but the proposal has been on the list and has not been received so well either.
Okay, I don't see anybody else coming up. And actually, we did very well this time regarding timing. It's five minutes to six. That leaves room for two small announcements.
I have been asked by the NCC to point out that there is a membership survey going on and those of you that are LIRs will be connected by the company conducting the survey, so don't be surprised.
And the second thing is there is a social tonight. It's a boat cruise on the creek, as far as I understand, unless I am mixing up days again, and the buses leave here, right in front at 7 and 7:30, in one hour and one hour 30.
With that, I conclude the Address Policy Working Group meeting for today. I hope to see you all back tomorrow at nine o'clock. Since there is no beer on the boat tonight, the chances are pretty good.
Thank you all for coming.
The session closed.