[routing-wg] Minutes RIPE 72

> On 26 Oct 2016, at 18:30, João Damas <joao at bondis.org <mailto:joao at 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-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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/routing-wg/attachments/20161027/b4366254/attachment.html>