<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">
<div class="moz-cite-prefix">On 2023-07-04 04:56, Douglas Fischer
via ixpmanager wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKEr4RRuucT_DvvBrKuP-PQi7jkWCW6mwkC8q6qsua1kgiXz+g@mail.gmail.com">The
more usual (and relaxed) syntax is AS65123::AS-CUSTOMERS, or
AS-JOHNDOENET<br>
<div dir="ltr">But the mor strict (and more correct, in my
opinion) syntax is RADB::
AS65123::AS-CUSTOMERS or RADB::AS-JOHNDOENET<br>
</div>
</blockquote>
...<br>
<blockquote type="cite"
cite="mid:CAKEr4RRuucT_DvvBrKuP-PQi7jkWCW6mwkC8q6qsua1kgiXz+g@mail.gmail.com">
<div dir="ltr"> the ASN operator is saying to the world:<br>
"The AS-SET that defines the cone of prefixes that can be
announced by our network is this one. And you should be
considered true just the information in the RADB IRR."<br>
</div>
</blockquote>
<p>Is that what it means, or does it mean "... And you should only
look for <i>this object</i> in the RADB IRR."? That's how I
understood it. And I think that's probably the <i>only</i>
realistic way to interpret it. Otherwise, you literally cannot
have cross-IRR relationships. In such a model, what is an
international ISP supposed to do? Or even an ISP that uses ARIN
but sells transit to someone that uses ALTDB or RADB.<br>
</p>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 2023-07-04 04:58, Nick Hilliard via
ixpmanager wrote:<br>
</div>
<blockquote type="cite"
cite="mid:74c84146-c58e-99d2-e95c-962ca872df37@foobar.org">
<blockquote type="cite">But the mor strict (and more correct, in
my opinion) syntax is RADB:: AS65123::AS-CUSTOMERS or
RADB::AS-JOHNDOENET
<br>
</blockquote>
<br>
currently unsupported due to lack of support with underlying
tools.
</blockquote>
<p>This is supported in bgpq4, which works fine with IXP Manager if
you have this trivial patch, which is in bgpq4 1.10 (and 1.11): <a
moz-do-not-send="true"
href="https://github.com/bgp/bgpq4/pull/90"
class="moz-txt-link-freetext">https://github.com/bgp/bgpq4/pull/90</a><br>
</p>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 2023-07-04 05:10, Barry O'Donovan
(INEX) via ixpmanager wrote:<br>
</div>
<blockquote type="cite"
cite="mid:978508fa-5377-73b9-9058-bcf2837d070a@inex.ie">If you're
suggesting we auto-update the AS-SET from PeeringDB after initial
onboarding, then that makes me very uneasy and certainly violates
the principle of least surprise. The relationship is between IX
and member directly, not via PeeringDB. <br>
</blockquote>
<p>
<blockquote type="cite">There may also be scope to allow a member
to opt in and say 'PeeringDB is the source of truth for my
network info, pull from there and update'. I'm not sure how
comfortable I am with this as an IX operator - would need to
think it through.
</blockquote>
</p>
<p>Consider this from the point of view of a network that connects
to many IXPs. If IXPs pull detail X from PeeringDB, then the
network only needs to update it once, rather than once per IXP.
Duplicating the as-set to each IXP (e.g. into IXP Manager) is
more-or-less only tenable because it basically never changes.</p>
<p>Consider how your position would work if the IRR entries
themselves had to be provided to each IXP. That would be a
nightmare!</p>
<p>To argue the other side a bit... There are disadvantages to
pulling things from PeeringDB. One is that if the information in
PeeringDB is wrong, the IXP operator cannot fix it. The
participant has to.</p>
<p>I've had conflicting input as to whether MICE should import email
addresses from PeeringDB (forcibly, overwriting what we have). On
the one hand, this relieves maintenance burden from us. On the
other hand, it will reduce the quality of our data where
participants do not care so much about updating PeeringDB.</p>
<p>We ultimately decided <i>not</i> to import email addresses. But
some of that was also that PeeringDB doesn't make email addresses
public, and we do, so it's questionable if we should be taking
from PeeringDB and then publicizing them--as opposed to
publicizing the (yes, typically the same) email addresses that
were given to us directly.<br>
</p>
<p><br>
</p>
<p>
<blockquote type="cite">I think there was talk on this list of one
IX writing their own scripts to do this.
</blockquote>
We are doing this at MICE, as are some others, I think.<br>
</p>
<p>In my case, the script I wrote pulls the as-set(s), max prefixes,
and peering policy from PeeringDB. If the as-set name(s) changed,
it triggers an IRR cache update for that AS in IXP Manager
immediately. If there is interest, I can provide that script
off-list, on-list, or whatever. It's not currently in a <i>public</i>
GitHub project, but I could split some of this stuff out from our
private repo if there's interest.<br>
</p>
<p></p>
<pre class="moz-signature" cols="72">--
Richard</pre>
</body>
</html>