PeeringDB "Restrictive" Policy

[rlaager]

PeeringDB supports the value "Restrictive" for the policy_general field: https://www.peeringdb.com/apidocs/#tag/api/operation/list%20net

This is not handled in IXP Manager: https://github.com/inex/IXP-Manager/blob/67d156f78c07a714270cdf7dcd264988fe419462/resources/views/customer/js/edit.foil.php#L127

I propose that it be treated as "Selective". If that is agreed, I will submit a PR.

[barryo]

PeeringDB have selective too though. I don't know what the semantic difference is between restrictive and selective?

We've chosen to not handle it for this reason - IXP Manager operator will need to make the call.

At INEX, our member application forms have open, selective, closed.

[rlaager]

The answer from PeeringDB:

there is no overall accepted definition. In short

selective: you have to meet certain criteria
restrictive: forget about getting a peering

DrPeering explains both terms in detail here [0]

[0] https://drpeering.net/FAQ/What-is-a-selective-peering-policy.php

which also links to here: https://drpeering.net/FAQ/What-is-a-restrictive-peering-policy.php

So it seems it's shades of grey:

• Open is "yes" or "yes, unless..."
• Selective is "yes, if..."
• Restrictive is "no, unless..."
• No is "no"

Looking at the networks on MICE that have Restrictive set, I'd say one of them is just wrong. (They peer with the route servers!) The other is, I think, meaningfully different than the others that are "Selective". The others that are "Selective" are either likely wrong (they peer with the route servers!) or tend to be content providers who will peer with most any eyeball network of non-trivial size. But the one "legitimate" restrictive is much more limited in who they peer with.

So I think it would be reasonable to align with PeeringDB and add a "Restrictive" option.

[barryo]

Thanks for getting the detail from PeeringDB @rlaager

restrictive: forget about getting a peering

So that's basically describing it as "closed / no".

You definition of Selective is "yes, if..." / Restrictive is "no, unless..." is basically describing them as synonyms.

My view would be the same: selective ~= restrictive and I'd be happy for the switch to match them on that basis. I would not like to see restrictive added as an option because it doesn't add value, just confusion.

[lucix-mich]

Hello Richard,

[...]

Looking at the networks on MICE that have Restrictive set, I'd say one of them is just wrong. (They peer with the route servers!) The other is, I think, meaningfully different than the others that are "Selective". The others that are "Selective" are either likely wrong (they peer with the route servers!) or tend to be content providers who will peer with most any eyeball network of non-trivial size. But the one "legitimate" restrictive is much more limited in who they peer with.

Don't confuse "peering with the route server" as equivalent to "open peering policy". It has nothing to do. Peering with a route server does not mean that a certain member would automatically send their prefixes to all other RS-connected members. We have a number of members who use route servers to get to the CDN caches, but don't go to anybody else. Community-based filtering is the key here.

Just to add this for clarification.

[lucix-mich]

I am wondering if the discussion on this issue here shows one of the fundamental "problem" with IXP Manager.

Of course the origin of IXP Manager is at INEX, and the community is very grateful for the work done by INEX and for making the result available to the community.

On the other hand how often are you forcing your own way of doing things on the other users? In this specific case, for example, I would expect I can tailor the peering policies I make available at my exchange, rather than having to copy exactly those used by INEX, including their term and their meaning.

If there is a generally accepted standard for routing policies, preferably from some RFC or BCP document, then it's fair to restrict to that list. If that is not the case, I would definitely like to see an option for customisation.

You have no idea what policies to publish? Why not use those of INEX, be my guest. You have other policies at your exchange and don't want to change? Customise the list, be my guest. You want to define 10 different policies? Man, I have no idea what that should be good for, but go ahead and be my guest.

I hope to find this open-minded approach more often, and would be ready from the LU-CIX side to help with contributions.

[barryo]

On the other hand how often are you forcing your own way of doing things on the other users?

I hope that after reading my reply you might agree that that's an unfair assertion.

Yes, IXP Manager has its origins at INEX but we endorse, subscribe to and adhere to standards and best current practices. Core to the 'good of the internet' mission of IXP Manager is that we do try to teach and implement best practice so that any IXP that uses it can benefit from the experience of all of the community that have contributed to the project - directly and indirectly.

The team behind this project have separately co-authored rfcs, helped develop standards, and participate in efforts such as working groups at RIPE, Euro-IX, etc. and MANRS. The output of these global-community efforts are then fed back into IXP Manager.

If there is a generally accepted standard for routing policies, preferably from some RFC or BCP document, then it's fair to restrict to that list. If that is not the case, I would definitely like to see an option for customisation.

Chatting with Nick internally here and his thoughts on this are:

In the case of peering policies, there isn't any consensus about what these terms mean in practice and there are no generally accepted external reference documents which we can use. We've come across big name Tier 1 transit providers who use route servers at some IXPs (not kidding!). We've seen "closed" peering policies meaning "we'll peer with anyone, just ask". We've come across (many) organisations with "open" peering policies who decline to peer with anyone. We've had quite a bit of internal discussion about what all these terms mean in practice. The only thing we concluded was that "open" means an aspiration to peer by default, "closed" indicates an aspiration to be picky (i.e. not actually "closed" because then they wouldn't be at the IXP), and that "selective" / "restrictive" were something between the two, but we couldn't even draw a real conclusion about whether "selective" was more open than restrictive, or the other way around, and found that most IXP participants took entirely random and arbitrary approaches to what they meant in practice.

I.e. ultimately, the terms are an indicator of a value judgement of a person in front of their computer somewhere, who made a call for what they thought was relevant to their organisation, regardless of whether that aligned with what the IXP might have thought the terms meant, or what anyone else might have thought either.

If these terms were more clearly described in an external reference document, that would probably make the case to define them in IXP Manager, but there would need to be some clear and generally accepted guidance first.

For me, I wasn't shutting down the discussion above re adding 'restrictive' as an option. I was asking for a generally accepted definition of selective vs. restrictive that would make it meaningfully useful to members of any IXP as to what the difference between the two was so they could make informed decisions about peering requests.

If the argument is 'add restrictive because PeeringDB has it', then my answer is that when speaking with someone in the PeeringDB project on this and why they had both, their answer was 🤷 . I.e. I'm not sure they really know why they have the two - historic artifact maybe? - and we've solved it by interpreting both as 'selective' when we pull that information from PeeringDB. I wonder would any value be lost if restrictive and selective at PeeringDB was condensed to one?

Finally, IXP Manager is in use in over 200 IXPs now so changes are not viewed through the perspective of "what INEX wants" or what "LU-CIX wants" but "what would be the effect of changing this be on 200+ IXPs?"

I would definitely like to see an option for customisation.

This is a very difficult area and we've learnt hard lessons on the propagation of customisable options.

• Anything that needs to be customisable needs to be programmed.
• This adds lines of code, database fields, additional MySQL queries and UI / config elements.
• These need to be tested and secured (see recent issues re XSS for example).
• These need to be supported, maintained and, in time, migrated / refactored as the code base changes. There's a significant element of embedded-expense here.
• We plan to add i18n support and this adds further complication to that.

There is a genuine long term cost to every feature, every database field, every line of code. It's a struggle to deal with this on a small team.

I'm also looking forward to improvements in the member-facing Peering Manager tool. If there is a set list of peering policies, then I can incorporate that information into programmatic logic to give members useful guidance and information. If they are customisable then I cannot do this; or I need to add many more lines of code to optionally ignore those features or interpret the customised policies. Standardising on a set list is definitely a bonus here.

Ultimately, we have made what we felt are reasonable calls for most of these, but we realise that other organisations will have different requirements. There's no way of getting full consensus on these but we try to get as much as possible where standards don't help.