On 26 Oct 2016, at 18:30, João Damas <joao@bondis.org <mailto:joao@bondis.org>> wrote:
Dear wg colleagues, I am sorry for the last posting of this draft minutes.
Meaning late posting, not last posting. Joao
Hope to see many of you tomorrow morning at 10:00AM in the side room at RIPE 73 Regards Joao Damas
Routing Working Group - RIPE 73 Thursday, 26 May 2016, 9:00-10:30 WG Chairs: Joao Damas, Rob Evans Scribe: Anand Buddhev
A. Welcome
Joao welcomed everyone, thanked the scribe, jabber monitor and stenographer. He then asked if there were any comments about the minutes of the WG session at RIPE 71. There were no comments, and he declared the minutes of RIPE 71 final.
B. Appointment of new co-chair
Joao thanked Rob Evans for his work as co-chair of the WG, and there was a round of applause for Rob.
Paolo Moroni volunteered to be a new co-chair of the WG, and Joao welcomed him.
C. "64-bit extended BGP communities" - Ignas Bagdonas
The presentation is available at: https://ripe72.ripe.net/presentations/156-ibagdona-extcomm-8byte-ripe72-1605... <https://ripe72.ripe.net/presentations/156-ibagdona-extcomm-8byte-ripe72-160526-final-43.pdf>
Paul Thornton said that this is a problem for new adopters who may only have 32-bit ASNs. He's had to give customers private 16-bit ASNs, or customers have gained a 16-bit ASN from acquisition. He said that having yet another solution to the problem may delay getting a solution from vendors. He suggested that the community of users should pressure vendors into delivering a solution quickly.
Ignas said that wide communities are not yet available, and while there are specifications out there, they are complex, so vendors are not implementing them. He also commented that 4-byte ASNs were still not that common.
Rudiger Volk (DTAG) said that problem should have been recognised sooner when 4-byte ASNs were being developed. He said that all parties are affected by this issue, whether one has a legacy 2-byte ASN or a new 4-byte ASN. He noted that discussions in IETF for extending communities been around for a long time, with no progress, and that in order to get concensus and implemented, we need to simplify the discussion, and just agree that the extended bits of the community are just transparent, like in the original specification of communities. This way, we might be able to get concensus and implementation from vendors.
Ignas replied that this minimalistic approach should be good enough for now.
Rudiger again emphasised that if we do this as a transparent bit string, it will allow additional use later, even though the encoding conventions may become messy in the future.
Geoff Houston had two comments:
1. He pointed out that there are 42,000 2-byte ASNs in the routing table, and 9604 4-byte ASNs, so 4-byte ASNs *are* widely used;
2. He invited Ignas to submit a draft to the IDR working group and try to get it through standardisation.
Ignas said that a draft was already in progress.
Randy Bush commented to Geoff that there has been a draft at the IETF for five years that is just now going into WG approval.
D. ENGRIT: Extensible Next Generation Routing Information Toolse - Stavros Konstantaras, NLnet Labs
The presentation is available at: https://ripe72.ripe.net/presentations/143-RIPE72_ENGRIT_SK.pdf <https://ripe72.ripe.net/presentations/143-RIPE72_ENGRIT_SK.pdf>
Andreas Polyrakis (GRNET) thanked Stavros for the presentation and said it was a useful tool. He commented on the performance and asked whether most of the work involved finding prefixes for each AS within an AS set. He asked whether the tool does any caching to improve performance? Stavros said all parsed ASNs are stored in memory, and need a lot of memory.
An audience speaker asked about reusing parsed results, and Stavros said that the tool currently doesn't persist any parsed information anywhere, so once it has parsed an AS, and exits, all the data is lost.
Rudiger Volk (DTAG) asked Stavros about his use of the word "parse". He asked whether it was parsing RPSL objects, or the filters embedded within them.
Stavros said that his tool wasn't actually parsing the syntax, since the syntax checks are done by the RIPE Database. He said that his tool was evaluating the filters to find out which prefixes are within which AS. He said that resolving this is what takes time.
Rudiger then asked whether the tool also evaluated AS path regexes in its evaluation, and Stavros said the tool doesn't support this now, but it's planned for the future, and that it wouldn't be easy.
Gert Doering noted that the folks who recursively include every AS into their AS sets should clean up their objects, because they shouldn't be including the entire Internet's worth of ASes into their AS set. Stavros noted that this was indeed a problem, and that sometimes evaluating such filters exceeded Python's recursion depth and crashed the tool. Rudiger Volk noted that there is a lot of crap, and that real-world filter evaluation may involve a lot of AS sets even if an AS is only announcing a small number of prefixes. He said that using IRR data in reality requires more scrutiny.
Jared Mauch (NTT) said that some customers' AS sets expand out to over 500,000 prefixes. Operators who build filter lists take a performance hit when using these, and we need to stop people doing this kind of thing to stop generating large configs.
E. RPKI Validator - Alex Band, RIPE NCC
The presentation is available at: https://ripe72.ripe.net/presentations/153-RPKI-Validator-3.0-RIPE72.pdf <https://ripe72.ripe.net/presentations/153-RPKI-Validator-3.0-RIPE72.pdf>
Peter Hessler (OpenBGPD) said that he wanted to implement RPKI validation into OpenBGPD, but hadn't had time to work on it. He also said that he had some ideas on improving the RTR protocol, to query not just for RPKI status, but also other information such as how long a prefix had been announced, or whether it was migrating from AS to AS. He said he would talk to Alex offline.
Rudiger Volk said that the documentation of the existing implemention is missing. Users needs to know about all the various failures users may encounter. He said that this requirement came up at the CIDR working group at the Buenos Aires IETF. He said it was not a good idea for one organisation to develop a large monolithic solution that does everything. He said the RIPE NCC should develop small, single-purpose tools, that can be integrated into other toolsets. He also suggested a workshop for users of these tools to discuss extensions and ideas for such tools.
Alex said that feedback doesn't always make it clear whether it's requirement or nice-to-have.
Tim Bruinzeels (RIPE NCC) said that he's writing an IETF document to document the algorithm of the RPKI validator.
Randy said that we need genetic diversity. He noted that the BBN validator wasn't in use, and we need at least two implementations. Randy then asked Rudiger whether he was running the validator in production, and Rudiger replied that he was running the validator every four hours, but not sure how he would use the results. He uses some of the results for special cases.
Geoff Houston (APNIC) said that RPKI was not built only for BGP. He said that BGP route validation amasses everything. But there should also be other use-cases, such as validation of single resources.
An audience speaker from PCCW said he would like to see the RPKI tool integrated into RIPE NCC APIs. He would like to run an instance in his own network, but would prefer a language other than Java, and offered Python as an example.
Andreas Polyrakis (GRNET) said he is using the RPKI validator in production and that it was easy to deploy, and would like to see continued development.
F. Making routing registries great again - Jared Mauch, NTT
The presetnationve is available at: https://ripe72.ripe.net/presentations/141-making_routing_great_again_ripe72.... <https://ripe72.ripe.net/presentations/141-making_routing_great_again_ripe72.pdf>
Peter Hessler (hostserver) asked who the users of this data would be. Jared said that he has spoken with other operators such as Level3 about how to solve this problem of bad data in routing registries. He said that adding the human cost to maintaining registry data makes it more reliable and trust-worthy.
Gert Doering said he likes that Jared has buy-in from other large players, because doing this unilaterally won't work. He wondered whether involving humans to manage this data would scale, but that was for the registry operator. He said that he prefers to buy NTT transit because it's good quality, and he would be happy to submit his route objects into such a registry.
Randy Bush noted that what Jared was attempting to build here was a web of trust. He noted that it was in a way, a sort of non-hierarchical PKI. He said there was a lot of work involved in doing this well, but he'd love to see it happen.
Jared compared his idea to that of buying a house, where someone attests that the property is indeed his. Randy said that it was good if the large operators could do this, but the thousands of small operators may not be able to. Jared then said that the big operators were doing different things, and if he could get them to normalise their standards, it would be a step in the right direction.
Rudiger Volk said he wasn't sure if Jared's idea would work for him. He said that different regions of the world have different needs, and that Jared's approach may be too US-centric. But Jared replied and said it wasn't his intention at all. He just wants to raise the bar of what goes into routing registries to make global routing better.
Joao commented that two parties don't need to be doing exactly the same thing.
Avi Freedman (Kentik) said that no one could possibly use one way to validate all the routes out there, and that having multiple efforts is a good idea. he said that this was interesting idea and effort.
G. Bogon ASN Filtering - Job Snijders, NTT
The presentation is available at: https://ripe72.ripe.net/presentations/151-RIPE72_bogon_ASNs_JobSnijders.pdf <https://ripe72.ripe.net/presentations/151-RIPE72_bogon_ASNs_JobSnijders.pdf>
Rudiger Volk said that AS 0 should also belong on Job's list, along with the large 4-byte ASN blocks in IANA's pools. Job replied that it was okay to do strict filtering, but please keep it updated. Rudiger also noted that specifying this in RPSL is actually hard.
Peter Hessler said that in the example configuration files of OpenBGPD there are prefixes that should not be allowed. He will look at adding examples of ASN filters too. Job said he will be happy to help.
John Heasley (NTT) said that AS_TRANS should not appear in the global routing table, and if it does, he wants to understand why. He thought it was probably a deficiency in some BGP implementation, or just bad configuration.
Randy Bush said that it would be very good to get router vendors to have a set to filter private ASNs. Job said he tried and failed. Randy said perhaps we should approach the vendors again, in larger numbers, to get this done.
Peter Hessler, speaking as the vendor of OpenBGPD, wishes to add sane default configs.
Session ended.