You're viewing an archived page. It is no longer being updated.
RIPE 59
RIPE Meeting: |
59 |
Working Group: |
Routing |
Status: |
Final |
Revision Number: |
1 |
- content to the Chair of the working group.
- format to webmaster@ripe.net.
RIPE Meeting: 59
Working Group: Routing
Status: Draft
Revision Number: 1
8 October, 2009, 9:00 - 10:30
9 October, 2009, 10:00 - 10:30
Chair: Joao Damas
Minutes: Franz Schwarzinger (RIPE NCC)
Jabber: Bert Wijnen (RIPE NCC)
First Session
A. Administrative Matters
The minutes from the RIPE 58 Meeting were approved.
B. IRRToolset Developments
Nick Hilliard, INEX
http://www.ripe.net/ripe/meetings/ripe-59/presentations/hilliard-irrtoolset.pdf
Shane Kerr (ISC) noted that whilst Nick had concluded that the toolset needs to die, the work he had done had ensured it would live for another ten years and Shane thanked him enthusiastically for it.
Nick acknowledged this.
Geoff Huston (APNIC) asked if he was correct in thinking that all you can usefully filter on with the toolset is prefix orign.
Nick stated that this is correct and that he found it especially useful when working with route servers. This is due to the difference between what ICP clients announce and the IRR database.
Joao Damas thanked Nick Hilliard for the presentation.
C. Practically Improving Security of Routing Information
http://www.ripe.net/ripe/meetings/ripe-59/presentations/volk-improving-security-routing-info.pdf
Rüdiger Volk, Deutsche Telekom
Daniel Karrenberg thanked Rüdiger via Jabber and stated that he is very happy about these meetings and that they were created by an Internet Society (ISOC) activity while he was chairing the ISOC Board. He also stated his concerns about the RIRs not being present at those meetings and asked if ISPs that were present didn't want them there.
Rüdiger agreed that it would be good to go have a larger audience but also stated that having a small group of like-minded people was extremely helpful.
Daniel said that the RIRs clearly recognise their responsibility for consistency of the number resource registries and that RPKI will be based on registry information. He asked Rüdiger to pass on his message.
Geoff stated that he is aware of the consistency and the accuracy of data in the RIR system is a known problem. He recognised old pre-CIDR allocations as being the biggest aspect of this problem. He stated that three or four months ago he could identify about 7,000 anomalies and that his organisation has been making efforts to reduce this number to zero. He assured that this problem is being worked on very hard.
Geoff also stated that judging from the work that APNIC did on RPKI it is important to know what it does and what it does not do. He explained that it does provide an alternative view of the allocation assignment database by formating it in an X 509 package. He said that due to the signed and singable nature of RPKI it is easy to identify who the current holder of a resource is. He also stated that APNIC trusts that this information will be useful but is not telling anybody how to use it.
Geoff finally stated, representing the IETF's SIDR Working Group as a co-chair, that they are three years behind the charter due to the lack of useful input. Instead of being constructive the group tends to stay idle for long periods. He would welcome further discussion on this topic at the next IETF meeting in Hiroshima. Geoff Huston asked Rüdiger if he was going to attend the IETF meeting.
Rüdiger stated that he hopes to go to the meeting.
Geoff asked if this appeal from an IETF SIDR WG co-chair would help to convince him.
Rüdiger stated that this might help.
John Schnizlein (ISOC) stated that he was the person who invited the group together. He said that he appreciates the details given in the report and that he will send out the draft soon. He wanted to offer clarification on the comments from ARIN that Rüdiger referred to. He said that the perspective that he heard was that the quality of data in different databases is better than the quality of the IRR. He also stated that it was his intention to only invite network operators.
Rüdiger Volk appologised for not thanking John Schnizlein explicitly.
Joao Damas thanked Rüdiger Volk for the presentation.
D. LISP Update
Vince Fuller
http://www.ripe.net/ripe/meetings/ripe-59/presentations/fuller-lisp.pdf
Tom Vest asked if any work had been done to anticipate the frequency or
scope of the RLOC renumbering events.
Vince noted that with LISP it is not necessary to do renumbering unless the connectivity to the Internet is changed due to switching providers.
Tom clarified that he was talking about inter-domain and inter-networking space.
Vince stated that this is a complex subject and Vince and Tom agreed to talk offline about this issue.
Joao thanked Vince for the presentation and explained that as there was one more presentation and no time left, an extra session will be held on 9 October, 2009 at 10:00.
The session ended.
Extra Routing WG Session: 9 October, 2009, 10:00
E. IPv6 Route Aggregation Recommendations
Rob Evans
http://www.ripe.net/ripe/meetings/ripe-59/presentations/evans-v6-routing-recommendations.pdf
Gert Doering (Address Policy Working Group (AP WG) Chair) stated that it these recommendations are an important thing to have and that he thinks this topic is suited for the Routing Working Group. He also asked how this should relate to the other RIRs.
Geoff Huston (APNIC) compared this to IPv4 and stated that it seems pretty clear that if an entity receives a block of address space, a huge number of small allocations tend to get further subdivided. It appears, in looking hard at updates and topology, that the reason for that subdivision lies in a combination of a richness of connectivity, multihoming, together with a desire to spread the load, not dividing it into the number of upstreams but dividing it into the number of traffic units that make sense. No one really wants to individually route individual customers but they do want the unit to be small enough that it makes traffic move from link A to link B.
Geoff continued that the problem is that any rule will run into issues. The predominant behaviour right now in IPv6 is aligned to two sorts of massive cluster points. There is a huge number of /32s and one third of the space; about 700 are
/48s. He said he worried about the /48s because they actually don't make much sense. He stated that in his opinion people are not thinking hard enough about routing. He said that there is some logical reasoning that when allocating in /32 minimum, it should be reasonably expected the the routing system will have /33s,
/34s, /36s and /37s due to moving customers around, which makes sense. He said that on the other hand, moving individual customers does not make sense.
Rob stated that these rules should not apply if two consenting ASes want to do this between each other.
Geoff said that no one has ever really taken the community seriously enough to limit their damage. He stated that it is a nice theory but in practice it doesn't exist.
Gert stated that he sees this from a slightly different angle than Geoff does. He said in his opinion, the importance of this document is to give people that consciously do what they do the leeway to do so and people that need strong guidance to do the right thing and to give them the guidance.
Geoff replied that he would see guidance in a statement such as "You should really think hard about the way you sub-divide your /32 in terms of addresses to groups of folk who become traffic engineering units". He also stated that an allocation will get split up and that people need to accept it. It's a case of providing some sensible guidance without saying, "Create as many /48s as will fit and see if the routing system enjoys what you have done". He said that it is important to have sensible guidance that allows for balancing traffic but also states that it is important to plan first and advertise second.
Rob stated that in an ideal world everyone would understand the routing tables and would break things up as it makes most senses in traffic engineering.
Gert replied that the focus should not be on traffic engineering alone. The reason why the AP WG brought this over to the Routing WG was that there were requests from people that have multiple disconnected networks and need to split their allocation purely for physical reasons.
Rüdiger asked if this should be fixed on the routing side or in the AP WG. He also offered to pay more membership fees as a solution.
Rob said that if a /36, for example, was a reasonable filtering guideline it will not fit all cases and starting another LIR would be the only solution.
Gert stated that one of the problems in the AP WG is that it is not possible to get another /32 if the first /32 is not full since people do not want to graciously give additional /32s.
Rüdiger clarified that the only way to get a new /32 from the RIPE NCC is by paying another membership fee and asks if the RIPE NCC members would want to support this.
Geoff talked about another observation: a /32 minimum routing unit doesn't protect a router from anything. If everyone advertised every /32, there are 4 billion of them, and /33, /34, /35 and /36 would be overwhelmingly large to routing technology as well. So, the number /32 is actually coming from an allocation policy and has nothing to do with routing. He said that he thought that this is almost a throwback to the AP WG. He found the observation that individual allocations tend to be split in routing is accurate in terms of what has been observed in IPv4. He asked how people should cope with terms of membership, minimum allocations and price paid.
Gert asked Geoff how APNIC had tackled the issue in the APNIC region.
Geoff answered that in the APNIC region they are now going down a path of liberal policies on accessing other /32s. The financial barriers to get there are now low, and certainly far less than EUR 5,000 in membership fees. His observation was that if someone or some party wanted multiple allocations, it's certainly not financial reasons that would stop them. The other part of this is the distinction between what you can sub-divide and what you cannot is perhaps not as strong a focus point as it is in the RIPE region. He was not sure how vigilant the APNIC region is as a community in looking at a minimum advertisement point in BGP. He stated that the real answer is in IPv6.
Gert said that it would be certainly valuable to have a strong guidance document for people who, for instance, just ignore advertisements.
Joao Damas said the strength of the document might be weakened if, in other regions, people just get extra /32s.
Geoff said that the whole push versus pull dynamic tension between large and small has happened before in IPv4, when Sprint drew a line for everybody but its customers in 1994. Looking at propagation of IPv4 prefixes today, one finds a huge gap between what people say and what people do. It is good to state some very tight principles about what we expect on scaleability of routing. It would be fantastic if there was a routing economy that we could simply say the market will decide since there is none at the moment. Everything comes back to address policy and the routing system is actually arbited by getting address blocks. People tend to advertise that in bulk, and then they tend to group it as a finer point. The document should say that "if your minimum allocation is a /32, you should think about a customer allocation plan that allows you to traffic engineer in a /36 and encourage that practice as a practice". But all one can do is gently suggest good and conservative engineering and hope that the big folk and the little folk agree with you. He asked if this explanation helped.
Gert said that it did not.
Jerome Durand (RENATER) asked how to handle addresses that have already been used and the problem of reviewing them.
Rob stated that it depends on which way the community wants to go. If a plan does not fit what the rest of the community wants it could mean that some people need to renumber.
Jerome said that he had started with multiple /32s about two or three years ago. People were already raising that problem and were discussing it. It is difficult to ask people to move to IPv6 without sending a clear message. The options are to either give people more addresses or give recommendations on deaggregation. He stated that he thought that this topic should go back to the AP WG since there are cases where it is not possible to get a new /32 from the RIPE NCC.
Rob said that the only way to get a new /32 at the moment is to meet the requirements or to set up another LIR.
Jerome referred to Geoff's statements and said that drawing a limit at /36 for instance is a good step forward. However, if everybody announces every /32 there will be a problem. He referred to the video in the EIX Working Group, saying that if there is no peering, there is also no transit. He said that it comes down to the way one manages their network and the most important thing is to trust the peers and the transit providers. He would prefer more freedom in order to not waste addresses and it should not be necessary to set up another LIR for more addresses.
Geoff stated that there is no 80% utilisation like in IPv4, but an H D ratio. He said that in IPv6 the utilisation does not have to be as high as one might think in order to get a new /32.
Marco Hogewoning (XS4all) said that people are too radical on this policy. He stated that as an operator, he filters everything below a /32. If people want business from his customers they need to play by his rules.
Rob agreed and said that this was a reason why the discussion was taken out of AP. The need for a document giving recommendations was seen.
Marco compared this to IPv4 by asking how many /16s are split up in /24s. He said that he accepted them at the moment but if too many people deaggregate he might set the boundary at /23 in order for his routers to survive.
Rob asked for a round up of the discussion. He asked if it is reasonable to move forward with this at the moment and if there are any objections.
Jerome said that it is a reasonable way forward but once the document is accepted it cannot be changed again.
Rob said that this should also go back to the mailing list in order to give people a chance to discuss this topic further.
Jerome agreed and said that it is important that the recommendations are stable and do not change.
Marco stated that if that document would not be there he might lower his filtering policy a bit to a /36. The only thing that this document does is actually put a little flag out there telling everybody take a /36 as a recommendation, both on advertising and in accepting, then at least we have got some level playing ground and it's no longer a 'Russian roulette' let way. He said that they should not set rules and everybody can do what they want with their network. But if somebody wants to send him 65,000 routes he will reject them.
Rob said that it will be a recommendation, not rules.
Geoff added that with any technology that is supposed to last for decades the rules will always change.
Rob said that some people on the mailing list had commented that it is too late since the /32 rule is already set.
Jerome agreed but said that it is important to agree together on the groups of rules. Problems haven been raised by the community and he thought that it was important to find a solution for them. A clear message needs to be sent.
Rob closed the discussion.
Z. AOB
None.
The session ended.
Actions: Rob to update the routing recommendations document.