<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><pre wrap="" style="background-color: rgb(255, 255, 255);" class="">Dear wg colleagues,</pre><pre wrap="" style="background-color: rgb(255, 255, 255);" class="">I am sorry for the last posting of this draft minutes.</pre><pre wrap="" style="background-color: rgb(255, 255, 255);" class="">Hope to see many of you tomorrow morning at 10:00AM in the side room at RIPE 73</pre><pre wrap="" style="background-color: rgb(255, 255, 255);" class="">Regards</pre><pre wrap="" style="background-color: rgb(255, 255, 255);" class="">Joao Damas</pre><pre wrap="" style="background-color: rgb(255, 255, 255);" class=""><br class=""></pre><pre wrap="" style="background-color: rgb(255, 255, 255);" class="">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:
<a class="moz-txt-link-freetext" href="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</a>
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 <b class="moz-txt-star"><span class="moz-txt-tag">*</span>are<span class="moz-txt-tag">*</span></b> 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. <b style="box-sizing: border-box; font-family: Helvetica, Arial, sans-serif; font-size: 12.24px; font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: 17.4857px; white-space: normal; widows: 1;" class="">ENGRIT: Extensible Next Generation Routing Information Toolse - </b>Stavros Konstantaras, NLnet Labs
The presentation is available at:
<a class="moz-txt-link-freetext" href="https://ripe72.ripe.net/presentations/143-RIPE72_ENGRIT_SK.pdf">https://ripe72.ripe.net/presentations/143-RIPE72_ENGRIT_SK.pdf</a>
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:
<a class="moz-txt-link-freetext" href="https://ripe72.ripe.net/presentations/153-RPKI-Validator-3.0-RIPE72.pdf">https://ripe72.ripe.net/presentations/153-RPKI-Validator-3.0-RIPE72.pdf</a>
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:
<a class="moz-txt-link-freetext" href="https://ripe72.ripe.net/presentations/141-making_routing_great_again_ripe72.pdf">https://ripe72.ripe.net/presentations/141-making_routing_great_again_ripe72.pdf</a>
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:
<a class="moz-txt-link-freetext" href="https://ripe72.ripe.net/presentations/151-RIPE72_bogon_ASNs_JobSnijders.pdf">https://ripe72.ripe.net/presentations/151-RIPE72_bogon_ASNs_JobSnijders.pdf</a>
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.</pre><div class=""><br class=""></div></body></html>