RIPE 73

Routing Working Group - RIPE 73
Thursday, 27 October, 10:00-11:30
WG Co-Chairs: Joao Damas, Rob Evans, Paolo Moroni
Scribe: Anand Buddhhev
Status: Final

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:
https://ripe73.ripe.net/presentations/149-ripe73.routingwg.azimov.pdf

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:
https://ripe73.ripe.net/presentations/152-Job_Snijders_RIPE73_Large_BGP_Communities.pdf

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 32. 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 32 and some 31, squatting on both unassigned code points, and Job said he would do that.

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:
https://ripe73.ripe.net/presentations/123-201610-MANRS-BCOP.pdf

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:
https://ripe73.ripe.net/presentations/158-ripe73-routing-ixp-hackathon-report.pdf

No questions or comments

F. AOB

Nothing