[ixpmanager] EuroIX and PeeringDB exporters

Arnold Nipper arnold at nipper.de
Fri Jul 30 00:57:11 IST 2021


Hoi Pim

On 29.07.2021 12:09, Pim van Pelt wrote:

> 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.
> 

may I suggest to make the export configurable. E.g. like

Status			Export	Export Name
Connected		yes	active
Awaiting X-Connect	no
Quarantine		yes	inactive


Viele Grüße
Arnold

> groet,
> Pim
> 
> On Thu, Jul 22, 2021 at 9:26 PM Pim van Pelt <pim at ipng.nl
> <mailto:pim at ipng.nl>> wrote:
> 
>     Hoi folks,
> 
>     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.
> 
>     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.
> 
>     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),
>      AND/OR
>     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)
>      OR
>     Is there another way for us to solve this issue with a mismatch on
>     turning up members on the exchange ?
> 
>     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) :-)
> 
>     groet,
>     Pim
> 
>     [0] https://docs.peeringdb.com/ix-f-json-import-rules/
>     <https://docs.peeringdb.com/ix-f-json-import-rules/>
> 
>     -- 
>     Pim van Pelt <pim at ipng.nl <mailto:pim at ipng.nl>>
>     PBVP1-RIPE - http://www.ipng.nl/ <http://www.ipng.nl/>
> 
> 
> 
> -- 
> Pim van Pelt <pim at ipng.nl <mailto:pim at ipng.nl>>
> PBVP1-RIPE - http://www.ipng.nl/ <http://www.ipng.nl/>
> 
> _______________________________________________
> INEX IXP Manager mailing list
> ixpmanager at inex.ie
> Unsubscribe or change options here: https://www.inex.ie/mailman/listinfo/ixpmanager
> 


-- 
Keep calm, keep distance, keep connected!

Arnold Nipper
email: arnold at nipper.de
mobile: +49 172 2650958

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <https://www.inex.ie/pipermail/ixpmanager/attachments/20210730/84a96b0b/attachment.sig>


More information about the ixpmanager mailing list