Peeringdb: Remove Virtual IXPs

[martzuk]

As per issue #455 , creating a new issue just for this.

I've noticed the proliferation of "Virtual IXPs", which by their nature aren't real IXPs.

Some examples:

LSY.CN (https://ix.lsy.cn/)

• https://peeringdb.com/ix/2598
• https://peeringdb.com/ix/2605
• https://peeringdb.com/ix/2606
• https://peeringdb.com/ix/2607
• https://peeringdb.com/ix/2608
• https://peeringdb.com/ix/2609

MoeIX (https://www.moeix.online/)

• https://peeringdb.com/ix/2443
• https://peeringdb.com/ix/2469
• https://peeringdb.com/ix/2566
• https://peeringdb.com/ix/2567

EVIX (https://evix.org/)

• https://peeringdb.com/ix/2274

I would propose, that since a virtual IXP is nothing but a few VPN tunnels, that they don't count as a real IXP, and as such are not listed on PeeringDB.

[as44980]

It could be that defining a "real IXP" is non-trivial, but if this is something we wish to do then perhaps the definition from RIPE's IPv6 Address Space Policy For Internet Exchange Points (https://www.ripe.net/publications/docs/ripe-451) could be a useful starting point?

An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity whose purpose is to facilitate the exchange of Internet traffic between ISPs.

[stillwaxin]

Open-IX has largely tackled this definition already and likely should be used as reference (which also is nearly exactly what is quoted from RIPE): https://open-ix.silkstart.com/cpages/ixp-technical-requirements

[martzuk]

"A physical network infrastructure operated by a single entity with the purpose to facilitate the exchange of Internet traffic between Autonomous Systems. The intention is to connect more than 2 Autonomous Systems, and there MUST be a clear and open policy for others to join."

Seems fairly reasonable to me. @arnoldnipper perhaps you would like to comment?

[arnoldnipper]

Open-IX has largely tackled this definition already and likely should be used as reference (which also is nearly exactly what is quoted from RIPE): https://open-ix.silkstart.com/cpages/ixp-technical-requirements

IX-F has a imho better definition, though not yet fully complete. The Open-IX definition is a bit vague imho. PC has addressed the definition of an IX (and also of a colocation) already several times and will further address it.

Once there is a definition the next challenge is how to check whether an infrastructure really is an IX

[as44980]

IMHO the open-ix definition is perhaps too detailed for this purpose, but it at least makes it clear that an IX is expected to be "A switch platform which allows any to any interconnection"..

Whereas the IX-F definition that an IX "is a network facility that enables the interconnection of more than two independent Autonomous Systems" would appear quite easy to argue covers a fully virtual 'IX' with no ability physically connect to it.

[as44980]

Once there is a definition the next challenge is how to check whether an infrastructure really is an IX

The real challenge is for an IX where the majority of the members connect virtually, but which has a physical presence somewhere.. which may or may not have any peers physically located there.

ie Bob registers his basement as facility in PeeringDB, then lists BOB-IX as being physically present there but also supporting connections via GRE, does this make it a "real IXP" ?

If so then perhaps #487 is relevant in that in addition to removing the outdated ATM media type, we could add Virtual (or GRE/EoIP/etc) as a media type and potentially retain Mixed for those IX's which support both physical Ethernet and remote/Virtual connections?

[job]

the open-ix definition doesn't seem designed to facilitate a concept but rather to create a special interest group for a subset of the Internet industry. What does _connecting virtually_ even mean these days with remote peering?

[martzuk]

I'd reason that there's a difference between an IX where a proportion of members connect physically and a proportion remotely, perhaps via a reseller vs. an IX where all members are connected via tunnels over the 'internet'.

[job]

I think the majority of AMS-IX and LINX these days is "remote", should
these be classified as "virtual"? Or perhaps the underlaying transport
technology is entirely irrelevant.

On Thu, Aug 8, 2019 at 3:09 PM Marty Strong [e-mail]
wrote:

I'd reason that there's a difference between an IX where a proportion of
members connect physically and a proportion remotely, perhaps via a
reseller vs. an IX where all members are connected via tunnels over the
'internet'.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/peeringdb/peeringdb/issues/515?email_source=notifications&email_token=AABFRWFNDTTK45NE6MA7Q2LQDQLJFA5CNFSM4HV27XX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD33RWYQ#issuecomment-519510882,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABFRWBBLUELZCB5SHDUPQLQDQLJFANCNFSM4HV27XXQ
.

[martzuk]

By remote, I'm assuming you are meaning router in another site, connected via DWDM. Or are you suggesting the majority of participants are reaching LINX/AMS-IX remotely via a reseller?

Would you not agree however, that AMS-IX/LINX or any other that offers resold ports are different to an IX built with just a bunch of tunnels?

[job]

Yes - with the large IXPs the majority (at least of new customers) these
days comes in through resellers that use some kind of technology to
transport the bits. It could be DWDM, VLAN, Pseudo-Wire, L2VPN, GRE, who
knows. It doesn't matter for PeeringDB, unless we start collecting &
publishing the interface methodology for all means of access.

I would argue that in context of the PeeringDB process, it does not matter
what the underlaying technology is. It doesn't seem to serve a purpose to
differentiate between virtual and normal IXPs. I assume that when people
join an IXP they'll do their homework up front to decide whether the IXP
meets their requirements or not.

On Thu, Aug 8, 2019 at 3:17 PM Marty Strong [e-mail]
wrote:

By remote, I'm assuming you are meaning router in another site, connected
via DWDM. Or are you suggesting the majority of participants are reaching
LINX/AMS-IX remotely via a reseller?

Would you not agree however, that AMS-IX/LINX or any other that offers
resold ports are different to an IX built with just a bunch of tunnels?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/peeringdb/peeringdb/issues/515?email_source=notifications&email_token=AABFRWFSFUKEVQC2HVOPF4LQDQME3A5CNFSM4HV27XX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD33SLDI#issuecomment-519513485,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABFRWDOMT4ICOOGYGVJ3Q3QDQME3ANCNFSM4HV27XXQ
.

[martzuk]

In which case, you define a collection of tunnels as an IXP?

[job]

that is what a lot of IXPs already are today, yes.

On Thu, Aug 8, 2019 at 3:20 PM Marty Strong [e-mail] wrote:
>

In which case, you define a collection of tunnels as an IXP?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[martzuk]

Citation needed

[job]

https://labs.ripe.net/Members/vgiotsas/uncovering-remote-peering-at-internet-exchange-points
https://www.de-cix.net/Files/b84ab9edaa214a049b0a367d8d43e6d02901343b/Research-paper-O-Peer%2C-Where-Art-Thou-Uncovering-Remote-Peering-Interconnections-at-IXPs.pdf
https://www.youtube.com/watch?v=vFuOTW-GDes

is recent research in this area

Anyhow, I like peeringdb to be technology agnostic, unless there is a very
clear and well defined benefit of not doing so.

In this product feature - if you dont want to connect to GRE or OpenVPN
based IXPs, by all means don't. But such IXPs may be a learning playground
for some people (that also want to make real-life peeringdb integrations),
or perhaps some weird technological restrictions apply forcing the IXP to
be operated in one way or another (there seems to be an infinite number of
deployment styles in the wild). Removing them from PeeringDB doesn't seem
to be useful

On Thu, Aug 8, 2019 at 3:23 PM Marty Strong [e-mail]
wrote:

Citation needed

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/peeringdb/peeringdb/issues/515?email_source=notifications&email_token=AABFRWDDXDYLEI2ZOVV3JELQDQM6LA5CNFSM4HV27XX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD33S7ZQ#issuecomment-519516134,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABFRWCTO5UBXRCHAT6YNI3QDQM6LANCNFSM4HV27XXQ
.

[martzuk]

Perhaps marking them in a different way would make sense, but I disagree that a learning playground made up of some lines of config on a server constitutes the same as a physical IX with some directly and other indirectly connected members.

[job]

If you single this type of IXP out, you'll need to classify all IXPs, and
some IXPs may be a mix of underlays & overlays; so we'd need to start
classifying all types of connections that can exist towards IXPs. This
seems a lot of work, for no apparent purpose in context of automation. The
decision to peer or not will differ from network to network.

Automation software will detect & set up connections according to the local
policy (do we peer with that ASN or not, is the next-hop latency acceptable
or not, etc etc)

On Thu, Aug 8, 2019 at 3:31 PM Marty Strong [e-mail]
wrote:

Perhaps marking them in a different way would make sense, but I disagree
that a learning playground made up of some lines of config on a server
constitutes the same as a physical IX with some directly and other
indirectly connected members.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/peeringdb/peeringdb/issues/515?email_source=notifications&email_token=AABFRWBECQ2NPKH57RXPVP3QDQNZTA5CNFSM4HV27XX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD33TWNI#issuecomment-519519029,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABFRWBGKZXFRRKSK2MIDBTQDQNZTANCNFSM4HV27XXQ
.

[arnoldnipper]

Fully agree to what Job says. As long as there is no need to differentiate, don't do. And also: you will have done your homework upfront before connecting to an IX. If an IX feels a need to tell more about themselves there is the notes field

[tpaseka]

PeeringDB's failure to define what an IXP is, is now allowing political hate to be spread by the platform.

This needs to be solved.

edit: included screenshot.

[job]

@tpaseka whether these are IXPs using openvpn, vxlan, or a hub is irrelevant. The lack of definition what an IXP is wouldn’t stop such an texts from appearing on PDB. It seems to me that the issue you raise is a concern with politically motivated expressions hosted on the peeringdb platform.

[lshiychina]

The ISO-3166 code and name are used in PeeringDB's pages
However.
The official name of the standard is Codes for the representation of names of countries and their subdivisions.
so the name should be "country / region" not only "country" to prevent political arguments.

[lshiychina]

LSY.CN's IXP is not a virtual physical access address such as LSY.CN Wuhan: LSHIY Group, No. 333 Jianshe Avenue, Jianghan District, Wuhan, Hubei, China, and there are ASN accessed through physical properties (including but not limited to: optical cables, cables).

[arnoldnipper]

The ISO-3166 code and name are used in PeeringDB's pages
However.
The official name of the standard is Codes for the representation of names of countries and their subdivisions.
so the name should be "country / region" not only "country" to prevent political arguments.

@lshiychina , would you mind to create a separate issue for that? Thanks

[lshiychina]

Dear Arnold
In your previous email, you said that if you want to change "country" to "country/region", you need to submit it it in Github, so I submitted it. I don't understand what you mean.

---

Shucheng Li

Wuhan LSHIY Network Technology Co., Ltd.

Tel: [phone]
Email: shucheng.[email protected]
Address: LSHIY Group, No. 333 Jianshe Avenue, Jianghan District, Wuhan, Hubei, China

信息安全声明：本邮件包含信息归发件人所在组织所有，发件人所在组织对该邮件拥有所有权利。请接收者注意保密，未经发件人书面许可，不得向任何第三方组织和个人透露本邮件所含信息的全部或部分。以上声明仅适用于工作邮件。
Information Security Notice: The information contained in this mail is solely property of the sender'sorganization. This mail communication is confidential.Recipientsnamed above are obligated to maintain secrecy andare not permitted to disclose the contents of thiscommunication to others.

---

From:Arnold Nipper [e-mail]
Send Time:2019年8月21日(星期三) 03:25
To:peeringdb/peeringdb [e-mail]
Cc:LSHIY [e-mail]; Mention [e-mail]
Subject:Re: [peeringdb/peeringdb] Remove Virtual IXPs (#515)

The ISO-3166 code and name are used in PeeringDB's pages
However.
The official name of the standard is Codes for the representation of names of countries and their subdivisions.
so the name should be "country / region" not only "country" to prevent political arguments.
@lshiychina , would you mind to create a separate issue for that? Thanks
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[arnoldnipper]

552 is fine, @lshiychina

[tpaseka]

raising this again, some more "virtual" IXPs appearing in peeringdb.

https://www.peeringdb.com/ix/2774
https://www.peeringdb.com/ix/2705

I can say with near certainty, that these IXPs (virtual or not) don't have presence in these cities.

While some physical IXPs are not being accepted and added
eg https://www.edgeix.net/ sydney - https://ixpdb.euro-ix.net/en/ixpdb/ixp/840/asns/

Has there been any progress on this? And how can we support new IXPs to actually get onto peeringdb....

[arnoldnipper]

While some physical IXPs are not being accepted and added
eg https://www.edgeix.net/ sydney - https://ixpdb.euro-ix.net/en/ixpdb/ixp/840/asns/

EdgeIX only now provided the information needed. AC treats and has to treat each request on an equal basis.

[arnoldnipper]

Still some more comments needed. @job and @arnoldnipper voted -1 so far. Make up your mind, @peeringdb/pc

[grizz]

I personally feel that these don't belong in PDB at all, but with my PC hat on, I have to vote -1 -- as Job said, it's a slippery slope once we start defining what a real IXP is, and we should be as agnostic as possible.

[arnoldnipper]

@martzuk, the quorum of @peeringdb/pc has come to the conclusion not to implement this. We leave this another five working days open for other members to comment on. If no one objects we will close this issue.

[andydavidson]

"it's a slippery slope once we start defining what a real IXP is"

Nobody is asking you to. Type "define:point" into google and it offers "a particular spot, place, or position in an area or on a map, object, or surface."

If an IXP can't point a position on a map, it's not an internet exchange POINT. Get this junk out of the database, please, before it becomes useless.

[joelfreak]

If we can't remove these items, can we at least have some field that asks if there is physical infrastructure?

[slampt]

I agree with @andydavidson.
That said maybe a compromise would be to identify Virtual IXPs as "Virtual" in PeeringDB.

[gavintweedie]

I think add "tunnel" or indeed the supported tunnelling types as a media type is sensible. Eg "Ethernet over IP" etc.
I note many, not all, of the tunneled/virtual IXPs are listing MTU below 1500, so that's one way to filter them for those that want to hide them.

I suspect most concerns, including mine, come from someone looking for an IX in a location and seeing what could be a list of many many IXPs (physical, remote and virtual) and then having no idea where to start to determine what meets their particular needs. For example a virtual (tunnel over internet) IXP could list every facility as enabled as long as you can buy IP Transit there. How do we display that? It's going to be a huge mess.

[hideyukisasaki]

I agree with @andydavidson and @narxnet. I think tunnel over the Internet should not be categorized as an IXP. We should have a way to recognize the difference between IXP and "Virtual IXP".

[job]

@hideyukisasaki should we also remove all entries participants that use a MPLS pseudo-wire to connect to BBIX? It doesn't make sense to me to be overly negative about one tunnel technology while at the same time happily use others.

@andyd Virtual IXPs as a concept can help younger people practise with the use and application of PeeringDB and related peering/BGP technologies. Even if you and I wouldn't use a particular exchange to exchange production traffic, it doesn't seem to me that there are downsides to PeeringDB or the community other than that it appears to provoke strong emotional reactions.

Virtually all IXPs have virtual participants... something to keep in mind.

[hideyukisasaki]

@job I was not try to focus on the technology. I wanted to discuss about the usability of peeringdb. I think managed MPLS based connection(or any of managed overlay technology) is completely different from the tunnel over the public Internet(which is best effort). I think what most of peeringdb users want is the information of Interconnection for the Internet Backbone(which should be high quality and circuits should be well managed).
I think the point that people are raising here is that we do not have the way to recognize if they are the IXP(which is for the Internet backbone interconnection) or just the playground.

People(especially younger people) are enjoying to practice BGP with various tunneling technology over the Internet. I respect these communities, however, I think the current way of information on peeringdb brings misunderstandings to the community and I am concerning about that.

[arnoldnipper]

Fully agree on what @job says. But let's rephrase the last sentence to: virtually all IXPs have participants connected via virtual interconnects.

You may however also look at #607 where we try to shed more light into how networks are connected to an ix

[arnoldnipper]

I think the point that people are raising here is that we do not have the way to recognize if they are the IXP(which is for the Internet backbone interconnection) or just the playground.

Honestly, how does the approach differ if a network wants to connect to what you call Internet-backbone-interconnection ix and a what you call playground ix? In both cases, you may find it worthwhile to connect or not to connect.

[martzuk]

"Virtual IXPs as a concept can help younger people practise with the use and application of PeeringDB and related peering/BGP technologies"

Can we have a playground flag?

[andydavidson]

"Honestly, how does the approach differ if a network wants to connect to what you call Internet-backbone-interconnection ix and a what you call playground ix?"

These is a huge difference between an IXP that makes a bit of internet where there would otherwise not be one, and a tunnel service which runs via an application on the existing internet.

"In both cases, you may find it worthwhile to connect or not to connect."

Maybe this is true but it doesn't mean that the tunnel-VPN-not-IXP should be listed as an IXP.

[job]

We don't have the technical means to differentiate between the various
types of interconnection technology employed by users of IXPs or IXPs
themselves. I don't consider attempting to define rules to show such
differences a productive use of time.

>

[arnoldnipper]

Honestly, an IXP does not create an internet. In a technical sense, it is infrastructure to allow for interconnection. And as @job pointed out several times already we do not distinguish between the various types of interconnection technologies.

Let's concentrate on more pressing issues to solve.

[arnoldnipper]

Can we have a playground flag?

For now, there is the notes field to express any specialities about your ix

[martzuk]

For now, there is the notes field to express any specialities about your

This is a feature request

[joelfreak]

These 'virtual' IXP's don't really have a city/country where they are located, however I can easily see them polluting the usefulness of the platform if somehow they aren't at least shown to be different from IXPs with physical switching hardware in a major city/building. I agree we need to not discourage small and new IXPs, however if we end up with people listing their IXPs in places where they aren't we may actually DISCOURAGE new platforms from opening when they believe they would be duplicative, and they aren't.

[arnoldnipper]

This is a feature request

Please open a new issue for this feature request then, @martzuk

[grizz]

There's nothing to implement with this, can revisit with the other tickets discussing how to address this.

[jranma]

Do IXPs, including virtual ones, allow route exchange between peers ? yes, the do.
Do IXPs, including virtual ones, use standard and recognized routing protocols ? Yes, the do
Are IXPs, including virtual ones, a basic infrastructure of the Internet? Yes, they are.

The decision to treat IXPs differently (or simply remove them) on the basis of the technology used is notbased on technical arguments, but on ideological choices.
Ideology and politics have no place in peerindb.

Everyone has the right to have their preferences. If you don't like an IXP, don't use it. Period. But you have no reason to forbid others to do so by denying them access to information.

This kind of half-worded paternalism about virtual IXPs is quite appalling.
Let's solve problems, let's not create them artificially.

[andydavidson]

Do IXPs, including virtual ones, allow route exchange between peers ? yes, the do.

Yes

Do IXPs, including virtual ones, use standard and recognized routing protocols ? Yes, the do

Yes

Are IXPs, including virtual ones, a basic infrastructure of the Internet? Yes, they are.

Virtual ones are not, they are an application that runs on the internet - tunnels across internet routed VPN.

IXPs _make new internet_, and the virtual not-IXPs _use the internet_.

This should be a database for people who need to procure and configure services to _make internet_.

[jranma]

Do IXPs, including virtual ones, allow route exchange between peers ? yes, the do.

Yes

Do IXPs, including virtual ones, use standard and recognized routing protocols ? Yes, the do

Yes

Are IXPs, including virtual ones, a basic infrastructure of the Internet? Yes, they are.

Virtual ones are not, they are an _application_ that runs on the internet - tunnels across internet routed VPN.

IXPs _make new internet_, and the virtual not-IXPs _use the internet_.

This should be a database for people who need to procure and configure services to _make internet_.

IXPs, physical or virtual, are not applications. They operate on layer 2/3, they don't "run on the internet", they allow networks to exchange routes.

I don't understand this "make internet" concept. The internet is a network of networks. Please remember that many of these networks are connected by.... tunnels. A large part of today's internet is made of tunnels. You don't like it ? All right, but that's not going to change. Hurricane electric, IPV6 largest network, allow for peuple and networks to get connectivity by tunnels.
Do tunnels break the internet ? They don't. Do tunnels add latency ? They surely do. When I'm in Europe and I connect to a website in Australia, I experience latency, too. Don't like this latency ? don't connect. Why should you impose your point of view to other people ?

Removing virtual IXP from peerindg will not make them disapear from the internet. It will just remove valuable routing information, a perfectly relevant information in view of perrindb's goals. On the other hand, identifying them as such would seem useful to me.

[as44980]

When I'm in Europe and I connect to a website in Australia, I experience latency, too. Don't like this latency ? don't connect.

Is this discussion still about PeeringDB, or is this now WebsiteDB?

Why should you impose your point of view to other people ?

A long, hard look in the mirror may be useful here..