<html theme="default-light" iconset="color"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head><body style="font-family: Calibri; font-size: 14px;"
text="#485663"><div style="font-size: 14px;font-family: Calibri;">Hi
Richard,<br><br><span>Richard Laager via ixpmanager wrote on 16/01/2024
01:10:</span><br><blockquote type="cite"
cite="mid:79955d67-cd3e-42d5-b40f-514b87bac2e7@wiktel.com">RFC 7947,
2.3.2.2.2 discusses BGP ADD-PATH. This is what I was looking
into which lead me here. I am looking at adding "add paths tx;" to the
route server template. However, this thread about a potential BIRD bug
gives me pause:
<br><a class="moz-txt-link-freetext" href="https://bird.network.cz/pipermail/bird-users/2024-January/017296.html">https://bird.network.cz/pipermail/bird-users/2024-January/017296.html</a>
<br></blockquote><br>at the time those templates were written, add-path
support was universally poor and there were no compelling reasons to
start deploying it at route servers because multiple ribs worked well.
Some of the limitations of the era still persist in some routing stacks,
e.g. support for add-path on ibgp only (huawei), or no support at all
(lots of stacks). Also, it adds complexity to an already complex
system. I'd argue that at the point that this makes a difference to
you, bilateral peering is likely to be a better option.<br><br><blockquote
type="cite" cite="mid:79955d67-cd3e-42d5-b40f-514b87bac2e7@wiktel.com">However,
if the IXP participant is filtering on receive, ADD-PATH can
still provide value. That is, if the participant would filter out the
best path (from the route server's perspective) but would not filter out
an alternate path, then ADD-PATH would allow that participant to use
that alternate path.
<br></blockquote><br>Yep, there are edge cases where add-path would have
a better outcome than not having it. The cost of this is additional
complexity, i.e. more likely to go wrong, and more difficult to debug
when it goes wrong.<br><br><blockquote type="cite"
cite="mid:79955d67-cd3e-42d5-b40f-514b87bac2e7@wiktel.com">My reasoning
about ADD-PATH largely assumes that receive-side filtering
could not be moved to the route server. I was also given this link (see
"IRRDB based Filtering"):
<br><a class="moz-txt-link-freetext" href="https://www.ams-ix.net/ams/documentation/ams-ix-route-servers">https://www.ams-ix.net/ams/documentation/ams-ix-route-servers</a>
<br>
<br>They have apparently implemented a script that honors:
<br><a class="moz-txt-link-freetext" href="https://www.ietf.org/archive/id/draft-ietf-grow-rpsl-via-01.txt">https://www.ietf.org/archive/id/draft-ietf-grow-rpsl-via-01.txt</a>
<br>
<br>That would be a lot more work to implement. Does anyone here know
AMS-IX
people? Would they be willing to share their script?
<br></blockquote><br>Their contact details are here:
<a class="moz-txt-link-freetext" href="https://bgpview.io/asn/52462">https://bgpview.io/asn/52462</a><br><br>The export-via / import-via hacks to
rpsl never made it to rfc status. Also, out of the tiny number of
people who use rpsl at all, most of these don't publish usable routing
policy using export/import / mp-export/mp-import.<br><br><blockquote
type="cite" cite="mid:79955d67-cd3e-42d5-b40f-514b87bac2e7@wiktel.com">RFC
7947, 2.2.3 says to preserve the MULTI_EXIT_DISC. Is BIRD doing that
(with the IXP Manager template config)?
<br></blockquote><br>yep bird does this by default in transparent RS
mode.<br><br>Nick<br><br></div></body></html>