<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Dear all,<div class="">I am attaching the minutes for our meeting during RIPE 73. I would like to greatly thank the RIPE NCC and in particular Amanda Gowland for getting these ready in good time.</div><div class="">Please post any comments, questions, etc regarding these minutes to the list before year’s end, when we declare them final.</div><div class=""> </div><div class="">As an additional note, no further comments have been received on the minutes for our meetings at RIPE 72 and therefore, as mentioned during the session at RIPE 73 we are declaring this final.</div><div class=""> </div><div class="">Regards</div><div class="">Joao Damas and Paolo Moroni</div><div class="">=========================================================</div><div class=""> </div><div class="">Routing Working Group - RIPE 73 Thursday, 27 October, 10:00-11:30 WG Co-Chairs: Joao Damas, Paolo Moroni Scribe: Anand Buddhhev A. Admin Joao Damas opened the session. He said that the minutes of the working group session from RIPE 72 were published quite late and apologised for this. He requested that instead of approving them in this session, people had a week's time to look at them, and then he would declare them final. B. ISP Border Definition - Alexander Azimov The presentation is available at: <a class="moz-txt-link-freetext" href="https://ripe73.ripe.net/presentations/149-ripe73.routingwg.azimov.pdf">https://ripe73.ripe.net/presentations/149-ripe73.routingwg.azimov.pdf</a> Joao Damas asked if the draft mentioned in Alexander's presentation would be submitted to the IETF. Alexander said that the first draft had already been submitted, and a second one was in progress. Joao then asked whether Alexander was doing the Bird implementation himself, and Alexander said yes. Rudiger Volk (Deutsche Telekom) asked whether Alexander saw a use-case for splitting a single AS for (usually) non-technical reasons. Alexander answered that when migrating, one is forced to migrate one ASN to another, but here one is free to unite or not. It's just an option. Rudiger then noted that the original design of BGP did not factor in commercial relations. C. Large BGP Communities - Job Snijders The presentation is available at: <a class="moz-txt-link-freetext" href="https://ripe73.ripe.net/presentations/152-Job_Snijders_RIPE73_Large_BGP_Communities.pdf">https://ripe73.ripe.net/presentations/152-Job_Snijders_RIPE73_Large_BGP_Communities.pdf</a> Rudiger Volk had several comments. He said that comparing large BGP communities with earlier proposals misses the fact that earlier proposals were inadequate. He said it was important to note in slides and documentation that large BGP communities do in fact fix the concerns operators had with 16-bit communities. Rudiger then noted that while the large BGP communities attribute is transitive, and should propagate everywhere, Job should not expect it to propagate everywhere, because some operators filter prefixes with certain attributes for security or other reasons. Rudiger was surprised that operators were not doing more filtering. Job replied that if more operators did such filtering, it would stifle innovation in BGP, because filters tend to become stale. He then added that if anyone *is* filtering BGP paths, then they should at least allow attribute 32 (large BGP communities). Wolfgang Tremmel (DE-CIX) thanked Job for this work and wondered why anyone else hadn't had this idea before. Warren Kumari noted that there was a lot of work involved and thanked Job for getting it done. Joao asked whether anyone had asked Juniper about their plans. Job said he had heard about implementation coming in 2017. Alexander Azimov asked if Job had asked Juniper, and Job said he had heard about it from friends, and that it was second-hand information. Alexander then asked which code point the implementations were using. Job said that some were using 30 and some 31, squatting on both unassigned code points, and Job said he would do that. </div><div class="">. He then said that the 32 code point had been assigned just hours earlier, but despite that the development pace was high, and some implementations had already patched their code. Job said that the time for changing the code point was right, because the only prefixes using it were the beacon prefixes. Leaving it to later would have made it harder to change the code point. Alexander asked if Job would update his slides to show the status of implementations' use of code point 30 and 31. Rudiger Volk said that while any serious vendor could patch their code for large BGP communities in 6 weeks, it will take much longer for it to be available at the edge because devices in production do not get updated so quickly. Peter Hessler (OpenBGPD) commented that he had updated OpenBGPD to use code point 32. He then noted that with the exception of the Cisco IOS-XR implementation (that one has to specifically request), all other implementations are currently in open source software, which will be easy to update. The place where large BGP communities will be most useful will on the route servers of Internet Exchanges, and since these all use open source software, it will be easy to deploy. Job remarked that the availability of open source BGP implementations has been a great help in developing large BGP communities. D. MANRS - Ben Maddison The presentation is available at: <a class="moz-txt-link-freetext" href="https://ripe73.ripe.net/presentations/123-201610-MANRS-BCOP.pdf">https://ripe73.ripe.net/presentations/123-201610-MANRS-BCOP.pdf</a> Joao said it would be nice to have a document that people can refer to, and asked Ben if he had any plans to work with the RIPE NCC to make this available in tutorials, for example. Ben said that there was still discussion going on about how to do this. He said that originally it was meant to become a RIPE document. But it's become too long and complex to be a RIPE document. So it may be better to have the principles of this in a RIPE document or something similar, and then refer from there to a more fluid documentation (such as a wiki) which can be updated more frequently, and make this available widely to the various registries and their communities. Joao asked the working group to review the document and provide feedback. E. "IXP Hackathon Report" - Robert Kisteleki The presentation is available at: <a class="moz-txt-link-freetext" href="https://ripe73.ripe.net/presentations/158-ripe73-routing-ixp-hackathon-report.pdf">https://ripe73.ripe.net/presentations/158-ripe73-routing-ixp-hackathon-report.pdf</a> No questions or comments F. AOB Nothing</div></body></html>