As mentioned during the meeting at RIPE 69 this week, we managed to drop the ball on sending out the minutes from the previous working group meting, at RIPE 68. We are posting those now, below, and open a 2-week period for comments.
Regards Joao Damas & Rob Evans Chairs, RIPE Routing WG === RIPE 68 - Routing Working Group 15 May 2014 14:00-16:00 Scribe: Anand Buddhev A. Administrivia João Damas, Working Group Chair, opened the meeting, thanking the stenographer, scribes and chat monitors. The minutes of RIPE 67 were declared approved and Joao asked the RIPE NCC to publish them. B. RDL: A Programmatic Approach to Generating Router Configurations- Benno Overeinder, NLnet Labs The presentation is available at: https://ripe68.ripe.net/presentations/366-ripe68-rdl-20140515.pdf Rudiger Volk, Deutsche Telekom, said that there was a big gap in the presentation about how policies can be applied, particularly in a modular way when a peer has an external relationship. He asked how well this model would work in the real world. Benno replied that this need more work, and he would be happy to involve Rudiger in it. Joao Damas said he understood how RDL helps with documenting, but didn't see the distinction between RDL programming the Autonomous System (AS) and configuring routers. Benno replied that these tools help shape our thoughts. RDL tries to express policy, and not to program routers. YANG and netconf can be used to actually configure routers, and RDL could be transformed into YANG; RDL is part of a toolset to configure routers. Geoff Houston, APNIC, said inter-domain routing is about negotiation. Peers express preferences. An AS cannot express absolute preferences. In routing, peers offer and accept. Geoff said that in RDL, things look more absolute, and can't quite understand what it might be useful for. Rudiger Volk said this engine has two views: one view shows inter-domain relations, which is public. The other view is for intra-domain policy, and probably internal and private. He asked whether RDL provides the ability to publish parts of the configuration as public and private. Andreas Polyrakis, GRNET, said that he was involved in the initial requirements gathering process, and was surprised by the presentation. He said that at the requirements level, many of Geoff's and Rudiger's concerns were listed. He said that RDL is a language to express policy, and a good language needs the ability to express different views of the policy, such as public policy that can be exported to the RIPE Database, and internal policy for use with neighbours. He said that the mailing list archives show that these requirements were indeed listed, but he wasn't sure how much of it was implemented in RDL. However he said Benno and Per were going in the right direction. C. Creating an Automated Prefix Filtering How-To - Job Snijders Job said that there was no good documentation about how to do prefix filtering. He wants the community to put together a how-to or document on how to do filtering, that can beginners can be directed to. He asked whether it was a good idea, and asked for volunteers. Some people raised their hands. Rudiger Volk said it was a good idea to write such a document, but that its biggest challenge would be to get figure out what reliable sources of data to use. Job agreed and said that he starts with the most accurate source and moves on to less and less reliable ones, and hopes for the best. At least documenting this process would be a big help to the community. Geoff Houston said this was not the first time such work had been attempted, and won't be the last time either. Job said he couldn't find references to any previous work. Geoff said it's difficult because one has to differentiate between customer and transit routes, and needs to know one's peer's policy. This isn't easy to do automatically. This is a long-standing problem, and is difficult to solve. He said that RPKI was invented to try and solve this problem, and the technology exists now, but nobody seems to be using it, and he doesn't know why. Job said that a small group of volunteers had stepped up to write this document, so he will set up a mailing list and get the work started. He also said that, if there is a need, they may write some helpful tools because the IRR toolset has been abandoned. Gert Doering, Spacenet, asked the room generally, on how we could get more people to filter. Many networks just accept junk. He referred to ISPs that accept all routes from customers without filtering. João Damas said that with such discussions, the problem is usually one of scope. Talking to external peers for filtering is dodgy. An audience speaker said it wasn't really about inter-domain routing, but more about transit carriers filtering routes from their customers. Rudiger said that a document on how to do filtering would help those who are not filtering. He said it is a valuable idea, but wasn't sure how successful will it be. Elvis Velea, V4Escrow, said that in Romania 99% of ISPs filter based on route objects. They mainly use proprietary scripts against the RIPE Database to generate filters. Gert was very happy to hear this. Elvis said he was surprised that, when he signed contracts with transit providers, they would allow him to announce any prefix without questions. An audience speaker said that, in Romania, most of the prefixes are filtered and must have a route object in the RIPE Database in order to be accepted. Mateo, Jaguar Networks, via remote participation, said that the main problem was getting people to update RIPE Database objects. The problem is worse when the customer is outside the RIPE region. An anonymous audience speaker said that in developing and emerging markets, customer networks change rapidly and is difficult to filter automatically. However, he thought that if there were a document, and perhaps tools to help, it would be appreciated. Elvis Velea said that even if a prefix is from outside the RIPE region, it can be added to the RIPE Database. D. Routing Resilience Manifesto- Andrei Robachevsky, Internet Society The presentation is available at: https://ripe68.ripe.net/presentations/365-20140515-Routing_Resilience.pdf Rudiger Volk said that he would be very reluctant to make statements about a minimum deployable state. A manifesto with minimum requirements has the danger that people who sign it will do no more than that. Setting a minimum target has the danger of not achieving much. This manifesto is a trade-off between a too low and too high mark. Andrei said this work has to start somewhere. Later, we can always introduce a second version of the manifesto with stricter requirements. Gert Doering disagreed with Rudiger. He said that it was important to reach many people. He said we should solve this problem ourselves before regulators come along and solve it for us, and it's a good way forward. He said that, if we reach this target and still need more, we can aim for a second version of the manifest. He supports this effort, and would be happy to have his company sign the manifesto. Daniel Karrenberg, unaffiliated, thanked Andrei for initiating this effort. He said that perhaps the principles should be formulated more generally rather than being too technical. A way forward, to avoid endless discussion, would be to describe the goals rather than a technical implementation. He then added that one should be be careful about perception of the third goal in the manifesto. He said that in this region we have solved it quite well, and having it in the manifesto may create the perception that there is a big issue to solve. Andrei Robachevsky asked Daniel whether some of the text was okay or not. Daniel said that some of the text was perhaps too short but added that Andrei should proceed with it. Andrei said he would take Daniel's feedback into account. Geoff Houston said that, in the IPv6 area, despite lots of documentation about how to implement it, people were not doing it. He said that a similar situation existed in routing. He argued that making such a statement would make it obvious that there exists a problem that is not being solved, and will invite regulatory intervention. Geoff pointed out the example of the route leak from an Indonesian operator, and said that it was not deliberate. He said that we need to understand the causes of incorrect routing, and solve that problem instead of stating the obvious with such a manifesto. Andrei said that the concept of the Tragedy of the Commons cannot be avoided in large communities. He said that our collective collaborative nature can help. He said that by having a manifesto, we make the statement more tangible and visible. Geoff said that this was not a tragedy of the commons type of situation. In a tragedy of commons, one's self-interest is stronger than the common interest. However, this is not the case here. Geoff said that routing problems are not necessarily about self-interest. He summarised by saying that the problem here is more difficult to identify, and that the concept of the Tragedy of Commons does not apply here. Andrei said he would talk to Geoff some more about this later. Sandy Murphy, PARSONS, said that network operators will use prefix-based filters, a common practice to solve the issue of identifying the legitimate origin of a prefix. This solution already appears in many documents about routing security and routing best practices. She asked what it will mean when an operator signs this document. Andrei said that signing this document will mean that an operator is not just agreeing to the principles, but applying them. It will create some sort of peer pressure, and thus carry more weight. He then said that more work was needed in the document to ensure that prefix filtering was not the only recommendation, but more of an example. E. BGP Blackholing Project – Join & Fight! - Łukasz Bromirski, Cisco Systems The presentation is available at: https://ripe68.ripe.net/presentations/369-bgp_bh_ripe.pdf Nick Hilliard, INEX, said that he really likes this tool from a technical viewpoint and would love to become involved in it. He said, however, that politically it is a disaster, and that all kinds of law enforcement agencies, courts and copyright holders would like it. He said it was a socially corrosive project, technically beautiful but covered in layer 9 issues. Lukasz agreed with Nick, and said that he was just trying to achieve something at a technical level. F. Setting up RPKI for Provider Independent (PI) End User Space- Alex Band, RIPE NCC The presentation is available at: https://ripe68.ripe.net/presentations/370-RPKI_for_PI.pdf João thanked Alex for his presentation, saying that that the process seems clear and simple. Erik Bais, A2B Internet, added that he had tried this tool. He asked how it would work for PI users who have moved to other sponsoring organisations. Alex said that he will look into this. G. RIPE Database Routing Update - Denis Walker, RIPE NCC During his presentation, Denis asked some questions of the community. His first question was about cleaning up the syntax of AUT-NUM objects in the RIPE Database. Rudiger Volk said that not everyone was using it in the same way, and that it should not be changed. Denis said he was asking for feedback. If the community feels that nothing is broken and doesn't need a fix then the RIPE NCC will do nothing. He then asked about deletion of orphaned ASN objects and what should be done. Alex le Heux, Kobo Inc., said that the RIPE NCC should do nothing. Rudiger Volk said that a cleanup is not necessary. He said that there's a lot of garbage in the various routing registries in the world. Denis said that "we" don't want garbage in the RIPE Database. Rudiger said that we should just leave things as they are, and not interfere with objects maintained by people. João Damas agreed with Rudiger. He said perhaps warnings were okay, but do not do a cleanup. Alex le Heux said that even warnings may be too much work. He said that the operational impact would be low to none. Nick Hilliard said that RPSL syntax was convoluted such that trying to clean up may cause problems. Denis Walker said that there was an action on the RIPE NCC from the RIPE NCC Services Working Group to clean up these references. João said that the consensus from the Routing Working Group was to not do any cleanup. Denis said that emails were sent to people to clean up their own objects and reference. Some people had done this but most had not. H. Charter Discussion João commented that only Job Snijders had sent feedback on the proposed new charter. He invited the session participants to read it and to comment on the mailing list so that it can be wrapped up before the next RIPE Meeting. Z. AOB There were no other points of business. João thanked the room before closing the session.
signature.asc
Description: Message signed with OpenPGP using GPGMail
