> On 26 Oct 2016, at 18:30, João Damas <[email protected] > <mailto:[email protected]>> 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-160526-final-43.pdf > > <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.pdf > > <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. >
