<div dir="ltr">Hoi IXPManager users,<div><br></div><div>Except for Arnold (representing the point of view of EuroIX / PeeringDB), I saw no responses from the IXPManager users. Barring objections, I'll file a github issue and work on changing the semantics in the IXPManager IX-F exporter to match expectations of PeeringDB. What this means, practically, is that ports that are not in 'connected' state, will then newly be added to the export, but setting the value of the 'state' field to 'inactive'. Please let me know if this is objectionable.</div><div><br></div><div>groet,</div><div>Pim</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 22, 2021 at 9:26 PM Pim van Pelt <<a href="mailto:pim@ipng.nl">pim@ipng.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hoi folks,<div><br></div><div>I was wondering if other folks in the community have advice for me. On my internet exchange, when setting new physical member ports, they typically start out as 'Awaiting X-Connect', until they move to 'Quarantine' and then to 'Connected'. I noticed that in the IX-F exporter, every state not 'Connected' means there is no entry at all for that member port. Often, new members will put their own assignment on their peeringdb page, often leaving the 'operational' checkbox unticked, to signal that they are in turnup.</div><div><br></div><div>However, the PeeringDB importer [0] does not align with these semantics. It will assume a member is in turnup if-and-only-if their port is marked 'inactive' in the IX-F feed. As a result, it triggers import warnings about members who have their port misconfigured.</div><div><br></div><div>Is it desirable to match the semantics in IXPManager (which I think means: all ports not in 'connected' state get exported in the IX-F feed but with state: inactive),</div><div> AND/OR</div><div>Is it preferable to change the semantics in PeeringDB (which I think might mean: do not trigger a warning if the member has a 'not operational' port set up, if it is missing in IX-F feed)</div><div> OR</div><div>Is there another way for us to solve this issue with a mismatch on turning up members on the exchange ?</div><div><br></div><div>I thought I'd gather some info from other operators before I attempt to file a github request (and/or send a PR for either IXPManager or PeeringDB, both, or neither) :-)</div><div><br></div><div>groet,</div><div>Pim</div><div><br></div><div>[0] <a href="https://docs.peeringdb.com/ix-f-json-import-rules/" target="_blank">https://docs.peeringdb.com/ix-f-json-import-rules/</a><br></div><div><br></div><div>-- <br><div dir="ltr">Pim van Pelt <<a href="mailto:pim@ipng.nl" target="_blank">pim@ipng.nl</a>> <br>PBVP1-RIPE - <a href="http://www.ipng.nl/" target="_blank">http://www.ipng.nl/</a></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Pim van Pelt <<a href="mailto:pim@ipng.nl" target="_blank">pim@ipng.nl</a>> <br>PBVP1-RIPE - <a href="http://www.ipng.nl/" target="_blank">http://www.ipng.nl/</a></div>