For an Exchange, currently "Media Type" has 3 options: Ethernet, ATM, and Multiple. I haven't seen any ATM IXPs in existence and searching for ATM yields zero. "Multiple" seems undefined or loosely defined at best. I suggest this field is either removed or deprecated or the options for ATM and Multiple are removed. If Multiple is to be kept it should be defined. When searching for Exchanges with Multiple there are only a handful and I suspect they are all really just Ethernet based Exchanges.
stillwaxin
All 10 comments
+1 for removal of that field. Or add "Token Ring" as well ;-)
arnoldnipper
on 4 May 2019
+1 kill it, no value
mcmanuss8
on 6 May 2019
+1, moving to decide Q
eloos
on 6 May 2019
[Edit} Changed my mind, -1 from me..
as44980
on 18 Jul 2019
Summary
Null out field and remove from UI, needs to stay in the data fields until API v3 (#625)
grizz
on 12 Jun 2020
[Edit} Changed my mind, -1 from me..
As #761 shows, its appears easy to confuse a lack of objections with something being a good idea..
So with that in mind, I feel I was too hasty in agreeing with the idea that "Media Type" was superfluous..
However with #782 I may have found a use for it ;)
as44980
on 27 Jul 2020
@as44980 Care to share your reasoning?
grizz
on 27 Jul 2020
TBH it was a result of the majority of the most recently updated Exchanges on the front page being "IX's" which it appears not to be possible to connect to via Ethernet, including IX42 LAS who advise "_Currently we only accept peers via tunnels due to insufficient fund for switch colocation_", which reminded me of there being at least some support within the swamp of #515 for the concept I have detailed #782 :)
as44980
on 27 Jul 2020
I don’t have an opinion either way, but were Media Type to be kept, I would make the following suggestion:
Remove ATM, change Ethernet to Physical, and add Virtual. Keep multiple.
I believe that would satisfy those wanting a way to avoid exchanges which can not be connected to physically since those could be labeled as virtual. It would also solve the issue of where to put the line between virtual IXPs. Those which do not offer physical connections would be virtual only. Physical only exchanges could choose physical. Those which have both could choose multiple.
Multiple would cover both large exchanges which offer remote peering, and those which offer both physical peering and “tunneled peering (over the internet) . . .” whatever you want to call it. An example of the latter would be EVIX which, despite only mentioning tunnels on the website, has a number of physical peers. Including “proper” cross-connect-in-a-datacenter peers too, not VMs or even dedicated machines.
Obviously, it’s difficult to find a good definition of the difference between those two categories which is why my method would group them together.
To be clear, I am not saying that there is a good reason for this change, but I do believe that it would be a reasonable solution to those who want some kind of indicator of virtual exchanges.
Bryce-MW
on 28 Jul 2020
I don’t have an opinion either way, but were Media Type to be kept, I would make the following suggestion:
Remove ATM, change Ethernet to Physical, and add Virtual. Keep multiple.I believe that would satisfy those wanting a way to avoid exchanges which can not be connected to physically since those could be labeled as virtual. It would also solve the issue of where to put the line between virtual IXPs. Those which do not offer physical connections would be virtual only. Physical only exchanges could choose physical. Those which have both could choose multiple.
Multiple would cover both large exchanges which offer remote peering, and those which offer both physical peering and “tunneled peering (over the internet) . . .” whatever you want to call it. An example of the latter would be EVIX which, despite only mentioning tunnels on the website, has a number of physical peers. Including “proper” cross-connect-in-a-datacenter peers too, not VMs or even dedicated machines.
Obviously, it’s difficult to find a good definition of the difference between those two categories which is why my method would group them together.
To be clear, I am not saying that there is a good reason for this change, but I do believe that it would be a reasonable solution to those who want some kind of indicator of virtual exchanges.
Given there appears to be demand from some users for the fucntionality you describe, but a lack of consensous to any of the soilutions proposed in other issue tickets, I would support this approach :)
as44980
on 8 Dec 2020
Related issues
vegu
·
7Comments
mahtin
·
12Comments
johannesmoos
·
12Comments
mwtr
·
8Comments
ccaputo
·
8Comments
Most helpful comment
I don’t have an opinion either way, but were Media Type to be kept, I would make the following suggestion:
Remove ATM, change Ethernet to Physical, and add Virtual. Keep multiple.
I believe that would satisfy those wanting a way to avoid exchanges which can not be connected to physically since those could be labeled as virtual. It would also solve the issue of where to put the line between virtual IXPs. Those which do not offer physical connections would be virtual only. Physical only exchanges could choose physical. Those which have both could choose multiple.
Multiple would cover both large exchanges which offer remote peering, and those which offer both physical peering and “tunneled peering (over the internet) . . .” whatever you want to call it. An example of the latter would be EVIX which, despite only mentioning tunnels on the website, has a number of physical peers. Including “proper” cross-connect-in-a-datacenter peers too, not VMs or even dedicated machines.
Obviously, it’s difficult to find a good definition of the difference between those two categories which is why my method would group them together.
To be clear, I am not saying that there is a good reason for this change, but I do believe that it would be a reasonable solution to those who want some kind of indicator of virtual exchanges.