Opening and Welcome – Paul Rendek, RIPE NCC
Paul Rendek welcomed attendees to the RIPE NCC Regional Meeting, Moscow 2005. He introduced the RIPE NCC staff and thanked the meeting sponsors.
Title: RIPE Policy Process
Speaker: Rob Blokzijl (RIPE)
Abstract: Introduction to the Policy Process in RIPE
Rob outlined how the new policy process is better organised. It used to be that policies were discussed at the meetings, but action was not always taken. Now the process is clearer as the next steps are defined.
Now we write down what we mean with our policy process.
It describes what we mean when we say ‘policy requests' – i.e. whatever comes out of the community – to the RIPE NCC, ideas from the community etc.
The steps of the policy development process are:
1. Creating a Proposal
2. Discussion Phase
3. Review Phase
4. Concluding Phase
Rob spoke about the new RIPE Meeting plan that includes more plenary sessions that focus on operational issues concerning the Internet. He mentioned that the plan is more streamlined with less tracks running, so participants usually get the full programme depending on their interests.
No questions followed this presentation.
Title: Introduction to RIPE/RIPE NCC
Speaker: Axel Pawlik (RIPE NCC)
Abstract: ‘RIPE' stands for 'Réseaux IP Européens', or European IP Networks. Started in 1989, RIPE is a forum where Internet Service Providers and others interested in the advancement of the Internet meet to discuss and work on problems common to all. In this session, we will present a short history of RIPE, describe how RIPE is organised, and discuss some of the current work in progress.
The RIPE NCC is an independent and not-for-profit membership organisation that supports about 3,400 members in more than 90 countries. This presentation describes how the activities and services of the RIPE NCC are defined, discussed, evaluated and performed in an open manner.
Title: RIPE NCC Activities Update
Speaker: Axel Pawlik (RIPE NCC)
Abstract: This presentation provided an overview of RIPE NCC activities including membership services, co-ordination activities and information services.
Axel explained the differences between RIPE and the RIPE NCC. Rob Blokzijl spoke on Internet resources, how they are coordinated on a global scale, and explained the organisations that are involved in the management of resources. He highlighted the policy development process and reiterated that the policies were accepted based on general consensus from the community.
Rob noted that, "The RIPE NCC is not RIPE. RIPE is not incorporated, the RIPE NCC is. The RIPE NCC hosts the open RIPE Meetings and the RIPE NCC acts as the secretariat for RIPE, giving coordination and services to the community. We needed a Network Coordination Centre because there was too much work for volunteers. We are neutral and impartial. We are set up to serve the industry and our members tell us what to do. The membership elects an executive board. Members guide our activities. Formally, the members approve the RIPE NCC Charging Scheme. They can participate on mailing lists. They don't have to come to the RIPE Meetings".
Axel described the situation of the other RIRs and the order in which they were set up. He mentioned that the RIRs formed the Number Resource Organization (NRO) as a coordinating body that acts as a common point of contact for outsiders. The Internet Assigned Numbers Authority (IANA), from which we get our address space, is part of the Internet Corporation for Assigned Names and Numbers (ICANN). In turn, we give the addresses to our members.
The RIPE NCC's Activity Plan contains proposed activities. This gets voted on at the RIPE NCC General Meetings, which are adjacent to the RIPE Meetings.
Axel spoke about the services that the RIPE NCC offers. These include:
• Registration services
• LIR Portal
• Training – new E-Learning portal
• K-Root Server
• Test Traffic Measurements
• DNSMON
• DNS infrastructure evolution
• DNSSEC
• RIS
• Statistics collection
• Autonomous System Numbers Missing In Action (ASN MIA)
• New projects
• Replacement of internal systems
• Software engineering
• Member Survey
• RIR coordination
Axel highlighted the following current issues at the RIPE NCC:
Outlook 2006
Stability of current services
Preparation on Certification of Resources
Preparation on Routing Security
He noted the next RIPE Meeting: RIPE 51 – Amsterdam, October, 2005, including the RIPE NCC General Meeting.
Questions followed later at the open microphone session.
Title: RIPE NCC Billing Administration
Speaker: Jochem de Ruig (RIPE NCC)
Abstract: The RIPE NCC Billing Administration presentation will highlight the changes that have been made following discussions during last year's regional meeting in Moscow and the discussions on the mailing list. The presentation will be split in two sections: the billing and contract administrative procedure update and the draft RIPE NCC Charging Scheme 2006.
The first section included an overview of the changes made to billing documents, a clarification of the structure, purpose of the billing documents and an outline for further improvements planned for 2006 (quarterly versus yearly invoicing).
The second section consisted of the changes made to the Charging Scheme, including the new Service fee scheme for 2006 and the new Billing Score Algorithm. The presentation covered the following topics:
• Billing and Billing changes – with focus on Russian billing and changes that were made for you this year
• Charging Scheme – new fee schedule for 2006, Billing Scoring Algorithm, membership developments in Russian Region
• General Information on Billing Statistics
• Billing Changes
• Ticketing system with ticket numbers (please use this number when you reply)
• TripleDeal payment system
• Revised Billing Scoring Algorithm
• Invoices in PDF format
• Changes made for Russian registries
• Quarterly invoices (sent one month in advance of the Quarter)
The following upcoming changes were also noted:
• Clear information on Billing Score
• New website for billing information (under construction):
– Payment possibilities
– Billing procedures
– Contact information
• New invoicing system in the course of 2006
• Further improve Billing mailbox response time
• New invoicing system in 2006
Questions followed:
On the RIPE NCC Charging Scheme:
Question from attendee: Will PI assignments be charged once? Or annually?
Jochem: It will be charged once on your annual service fee. That is, say you got a PI or ASN number in January 2005; we would take it into account for this year's score and will include it in all of your other allocations. But for next year, it won't be included. So, it's a one time fee.
Question from attendee: Of course paying your invoice once a year is more convenient and it generally is better for us. But Central Bank regulation forbids us from paying money abroad, more than three months ahead of that. Unfortunately, we have no control over that three months time frame. We do like paying your bills but on condition, however, that we get them on time, and on the condition that we get our acceptance act, and on condition that we have such an agreement that gives us a chance to make sure that we pay all our taxes right, and that our tax situation is clear. These are the three main points that you touched on in your presentation. I think these three issues have been resolved now to a large extent because we get an invoice which is clear to every accountant. We get an acceptance act which is in full compliance with the invoice, and third, we now have this extra service agreement which clearly states for what kind of service we are paying. We can take a look at the Russian tax code and in Article 148 item paragraph 1, subparagraph 4 we can see that this is the kind of service which is not VAT taxable. So we have clarity everywhere now. And now we do love paying your bills. So thank you for your great work that you did for us and indeed working with this contract is now a pleasure. Thank you.
Jochem: Thank you for your kind words. It's very important that you notify us if you see a change in legislation or it you see a problem with the document because it's difficult from our side to hear that and know if there is a change coming. So just send a mail either to us, or the mailing list so we can talk about what changes need to happen so you can continue to love us.
Question from attendee: Is there a price difference for Russia in paying a yearly invoice and a 3-month invoice? Because in the past I remember you charged EUR 50 for a yearly invoice or quarterly invoice. Do you have this charge now?
Jochem: At the moment, for 2005, we do have that charge. It's EUR 25. In view of the continuous legislation problems that you have, we'll look into it for next year, whether we have to continue it. At the moment yes, we do have an extra charge for people with a quarterly invoice because there is extra work involved.
Question from attendee: When we paid our last invoice of 2005, we got a yearly invoice and this caused problems. If you break it down by quarters for 2006, we couldn't do it in advance. You said we were supposed to do it in months prior to the 2006 invoice. When are we supposed to do that? So when do we instruct that we are going to pay in four pieces/quarters for 2006? When are we supposed to let you know?
Jochem: As soon as possible. For Russian members, we always will change your billing scheme because we know the problems you have here. So if you want to change to a yearly invoice or half-yearly or quarterly invoice, we will change it. Send an e-mail and we will amend it and correct the invoices. Please send it to [email protected].
I have one last comment to make. For those of you who haven't signed the new Service Agreement (the framework contract), please send it to us very quickly. Otherwise, we might have to stop your services if we don't get the contract back. I have some contracts here for those attending, so I hope to catch you at some point during the day and can hand you the contract. This is very important for us to continue serving you as one of our members.
Coffee Break
Title: Services to help you understand the behaviour of your network
Speaker: Henk Uijterwaal (RIPE NCC)
Abstract: The RIPE NCC offers a number of services that collect data on the Internet with the goal of helping operators to better understand the behaviour of their network. These services are: Test Traffic Measurements (TTM), a service that measures key performance parameters such as delay, loss, jitter and IP-level routing; Routing Information Service (RIS), aimed at BGP inter-provider routing; and DNSMON, a service that monitors the performance of Root and TLD servers.
In this talk, a brief overview of these services was given. These services are available to the entire RIPE NCC membership, often at no additional cost. Also discussed were the relation of these services to other activities of the RIPE NCC and show how the entire portfolio of services can be used to your benefit. RIPE NCC staff was available afterwards to demonstrate these services and discuss possible applications for specific cases.
Question from attendee: What kind of traffic do you use for measurement? Because there are slightly different data in TCP traffic: UDP, ICMP etc. I know that, in some cases, some kinds of traffic go through satellite, some from optic and so on.
Henk: We use UDP and the packets resemble as close as possible UDP packets that any user would send. We did some studies on this and, while it's odd, at that time we didn't see any differences between TCP and UDP. We did see differences between UDP on the one hand, and ICMP on the other hand. So we decided not to go to ICMP.
Question from attendee: Do you have plans to monitor some kinds of traffic for one point, some different graphs for TCP, UDP, and web traffic so you can see all the graphs, not only one type of graph?
Henk: I think, in the present set-up, it wouldn't make much sense to distinguish between TCP and UDP. The problem I would have is if you want to analyse the traffic coming into the sites, you enter the area of passive measurements, where you actually have to set up a tap to the ingoing or outgoing feed of a provider and look at the individual user data. This is something we've always refrained from doing since people don't like it if we start spying on the data.
Question from attendee: When you set up a test traffic measurement box, do you think all kinds of traffic goes some ways and has the same priority?
Henk: Yes. The way we install the boxes is that we set it up near the edge of a provider and we ask it that traffic coming to and from the box is treated in the same way as that from his regular users. We are aware that if people want to do this, they can actually do all kinds of traffic shaping and all kinds of things on their routers that would make the results look better. But then again, you're shooting yourself. If you want to manipulate the traffic coming from the device that you installed to measure the performance of your network, you're free to do so, but what's the point.
Question from attendee: No, that's not the question. For example, we have highly overloaded link and we are setting priority of ICMP for voice traffic and mobile priority for web traffic and ftp traffic. So, can your device build graphs and get statistics for all kinds of traffic?
Henk: No, not at the moment. But if there is interest from the community, then it is certainly something we can do. What we basically do now is to generate standard UDP packets, but our software allows us to set all kinds of things in those packets and generate difference kind of packets. So this is something we can do. This is the first time we have such a request, so don't pin me down on a schedule. But if there is interest, then it is something we can investigate.
Question from attendee: What is the privacy policy on the data? Is it available to bank customers or anyone on the Internet?
Henk: The policy is essentially that you get all the data related to the box installed at your site and internally you can do what you want with it. Then we give data away for what we call “statistical and scientific analysis” and people can again do what they like with that. However, if you publish outside your organisation, you have to anonymise your data so instead of calling the companies by name, call them ISP-A, ISP-B and ISP-C etc. The paper you publish has to be distributed to the other users of the service first, so they can comment on it. So when you give out the data to other organisations, you sign an agreement with them.
We have a document that specifies this in more detail and in legal English, but this is the gist and we ask people to sign it.
Question from attendee: Suppose we want to sign a note for this system, we should buy the equipment from the RIPE NCC? And we should also pay a monthly fee?
Henk: The machine costs between EUR 2000 and EUR 2500. The service fee is EUR 1000 per year.
Title: Policy Development Process (PDP)/Registration Services
Speaker: Leo Vegoda (RIPE NCC)
Abstract: This presentation introduced RIPE's formalised Policy Development Procedure (PDP), as documented in "Policy Development Process in RIPE" (ripe-350). It explained the areas addressed by the PDP, the places in which discussions occur and how to become involved in creating RIPE Policy. Additionally, the presentation explained how the RIPE NCC, RIPE's secretariat, supports the process and the people proposing policies.
There were no questions.
Title: NRO Statistics
Speaker: Leo Vegoda (RIPE NCC)
Abstract: This presentation showed a quarterly snapshot of the status of the IPv4, IPv6 and AS Number resources managed by the five Regional Internet Registries (RIRs). It was intended to complement the raw statistical data sets published each day.
There were no questions.
Title: IPv6 Consumption
Speaker: Axel Pawlik (RIPE NCC)
Abstract: This presentation showed results from recent research into IPv6 consumption statistics.
There were no questions.
Title: World Summit on Information Society (WSIS) Update
Speaker: Axel Pawlik (RIPE NCC)
Abstract: Axel gave a short presentation on the latest developments in the WSIS process.
There were no questions.
Title: Internet Engineering Taskforce (IETF) Overview
Speaker: Alex Zinin (Alcatel USA)
Abstract: Alex provided a short introduction to activities of the Internet Engineering Task Force (IETF), the engineering and standards organisation for the Internet, where Alex serves as co-director of the Routing Area. This was followed by the description of recently approved standards and a discussion of newly emerging efforts, such as Path Computation Elements (PCE), Layer-1 VPNs (L1VPNs), and IP Fast Reroute (IPFRR).
Alex outlined the structure of the IETF, including: General, Internet, Routing, Operations and Management, Transport, Security and Applications. Alex then went through the recently approved proposals through the IETF, as well as the policy proposals that were currently in progress. Alex reiterated the fact that feedback was always welcome in this process. The various working groups of the IETF were defined and discussed.
Question from attendee: We need feedback on how you normally apply BGP attributes and how do you manipulate the AS. We all know basically how it's done but the working group would be interested to know how you manipulate them and how you use them. And what is your feedback on what is to be a secure BGP mailing list?
Alex: In principle, if you want to subscribe to any BGP mailing list, visit: www.ietf.org. On the front page, you will see working groups. Log in and see the list of where to send e-mails. You will see all the information of the working groups and will be able to subscribe. You can do it today.
Question from attendee: Fortunately, there is a solution to this problem and the IETF is looking at this solution. What is the status of this standard in the IETF? What is the status of this job?
Alex: A few years ago, there was a proposal on how to translate BGP from 2 byte autonomous AS Numbers to 4 byte autonomous AS Numbers. The job status expires in six months. It is deleted from the directory if it's not updated and if nothing is happening with the draft. That is what happened with this draft. We have a potential solution and we know how to do it. There is discussion about the best way to do it. There is no implementation and this is one of the issues here.
It is important what services providers ask vendors. The vendors will never say 'we'll do that'. Unless they see that the service providers are eager to do that. If it is important, then you must ask your service provider. Everything is in your hands.
Question from attendee: Have there been any attempts to include information from the global route registers to BGP second solutions?
Alex: There have been attempts. The problem is that information in those registries is not 100% accurate. Not all people contribute their information to this registry, so it's not always updated.
Alex: I propose that you subscribe to the mailing list and ask the questions there.
Question from attendee: This FRR technology is it implemented? IP FRR.
Alex: Yes, it does exist. There is one implementation of basic IP FRR. One of the vendors implemented this and did a demo.
Comment from attendee: They implemented in the hardware.
Alex: In terms of operations, I don't have any information here.
There were no further questions.
Title: ccTLD.RU current state
Speaker: Pavel Khramtsov (RU-CENTER)
Abstract: The presentation included information on the number of .ru domain registration per regions, milestones, domain names registered by registrars, the growth of .ru domain name registrations and a measurement toolkit.
Question from attendee: You said that you monitor DNS services every day and 80% is Bind. What is the other 20%?
Pavel: Mostly, we use Bind version 9. The rest is version 8 and the other 20% is difficult to know because this includes those who haven't responded. We don't look at milestones as reference points.
Comment from attendee: You say they will register domain names to use as indices in search engines not for cyber squatting.
Pavel: As I showed you, we're talking about domain names registered to person or a one legal entity. You're talking about transfers and how many take place a year? I don't have this information, as it is something we don't take into account.
What is the time frame after which you consider this domain registered?
Well, 80% registered take place on the same day. On average, registration time is immediate as robots do it automatically.
There were no further questions.
Title: Moscow Internet Exchange (MSK-IX)
Speaker: Alexander Ilin (MSK-IX)
Abstract: This presentation was a short overview of customer services of MSK-IX, hardware internal structure, technical requirements, statistics, monitoring and troubleshooting.
Question from attendee: In keeping in mind the blackouts we had in Moscow in spring, I know that many people who were connected to you had a lot of problems. What will you do to avoid those problems in the future?
Alexander: Let's go a few steps back. We have quite a good redundancy and back-up systems. Historically, most ISPs live on MTS9, probably 80% of them. The problem is, if this facility is disconnected, everything crashes. The problem was that there were no ISPs there. The rest were working, even the route server was working at MTS and those with connections to the route servers could connect to each other and it was working. We just had fewer ISPs and, after this blackout, people looked at statistics and were looking to the second line, to a different point, because that was quite expensive for them.
A discussion ensued about what happened during the blackout.
The director of MSK-IX explained that they are tenants of MTS9 and would never be allowed to set up generators on the 12th floor. She asked for understanding that they could never reach 100% stability and could never avoid things like natural disasters.
Comment from attendee: Sometimes we notice route leaks and sometimes the connection to the server becomes unsafe. Perhaps we should develop a penalty policy so we could suspend them.
MSK-IX: According to MSK rules, we can disconnect the violators. As when we had these route leaks, that participant was disconnected almost immediately. They didn't agree as they said it wasn't critical. We met with them and they realised their fault in this. It's difficult to monitor. Please let us know if you see violations with ISPs and we will work with them to resolve the issues.
Comment from attendee: Following up, maybe we can provide a framework for dealing with ISPs? You have some recommendations, so please publish them so we can all see them. Please also give early warning mechanisms and coordinate your activities with this service so you can monitor the route leaks.
With regards to energy saving and power supply and temp regime at MSK-IX, we have a node in the same facility and our second in London. The quality of service is not comparable. I have two routers and one access point. Why can't I use addresses given to me by different routers?
MSK-IX: These rules were not just made up. The problem is that if you use two addresses and if you have problems with your connectivity. We will disconnect both of your connections. We can't block one address without blocking the other. We can't separate them. It's up to us to monitor that. If you have a technical question, you must please write to our technical administration. Following up. Did you compare the prices of Moscow exchange with the London exchange? Is it comparable?
Question from attendee: As far as I could see, total traffic evaluations at MSK-IX were approx three gigabytes. From which ports do you monitor general traffic?
MSK-IX: You collect data from client ports and get a total traffic. There are no other ways of collecting this information.
Question from attendee: So no switch? Where total connectivity would be higher then one gigabyte?
MSK-IX: It's more than 3GB per stats. We don't break it down per switches. It's a whole structure.
Comment from attendee: You mentioned software. So this should get all the traffic from the IX.
MSK-IX: No. The software sits in a free port listening to the traffic which goes to a participant who just got is just connected. So the broadcast as unknown. The switch doesn't know where to send it. So it sends to straight port.
There were no further questions.