search

peeringdb / peeringdb

Server code for https://www.peeringdb.com/
BSD 2-Clause "Simplified" License
340 stars 111 forks source link

Add a Virtual IX Flag field to IX Object #1557

Open martinhannigan opened 2 months ago

martinhannigan commented 2 months ago

Is your feature request related to a problem? Please describe.

We can't tell the difference between a virtual IX or a physically present IX without a ton of effort. It's a time waste for many since virtual IX's serve a fairly different purpose than traditional IX's.

Who is affected by the problem?

Users of PDB

What is the impact?

Pretty good. We can sort out the difference for either one (I want to see vIX, I want to see IX) and have a happy experience.

Are there security concerns?

Yes. It is important to understand the true definition of IX objects on the platform and provide an easy way to identify its different uses.

Are there privacy concerns?

No. PDB is a public registry. It's just a feature to compliment search and export.

Describe the solution you'd like

Add a field to the IX object specifying if it's a virtual IX or not.

Do you think this feature will require a formal design?

Perhaps

Describe alternatives you've considered

Doing nothing which is less than optimal.

Could this feature request need support from the Admin Committee?

Probably not.

What is the proposed priority?

High, aligns with https://github.com/peeringdb/peeringdb/issues/1556 and is probably a dependency order of operations wise.

*

job commented 2 months ago

Wasn’t this discussed a number of times before, with the main issue being that it’s hard to define what a “virtual” IX is?

martinhannigan commented 2 months ago

I don't think it's too hard at all - but it also seems out of scope at this stage.

On Fri, Feb 23, 2024 at 3:18 PM Job Snijders @.***> wrote:

Wasn’t this discussed a number of times before, with the main issue being that it’s hard to define what a “virtual” IX is?

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1557#issuecomment-1961935035, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQWJC6OE2Y7B4ZLRZWDYVD2RLAVCNFSM6AAAAABDXJGZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRRHEZTKMBTGU . You are receiving this because you authored the thread.Message ID: @.***>

job commented 2 months ago

Definitely seems in scope, because what does the field mean? Who owns the field? Who can change it? Is this remote peering? What’s the plan if one party asserts that another party filled the field incorrectly?

I don’t think we can ignore all the previous discussion on this topic and ignore that there was no consensus

grizz commented 2 months ago

After hours of discussion, this was solved and never implemented. I somehow knew this was going to come back :)

As I recall, the solution was to require a facility for the IX, with easy to click options (as dummy Fac objects) including Virtual.

martinhannigan commented 2 months ago

On Fri, Feb 23, 2024 at 3:24 PM Job Snijders @.***> wrote:

Definitely seems in scope,

It's not.

because what does the field mean? Who owns the field? Who can change it? Is this remote peering? What’s the plan if one party asserts that another party filled the field incorrectly?

Its far more simple. Is it a facilities based IX with a switch fabric or not?

I don’t think we can ignore all the previous discussion on this topic and ignore that there was no consensus

When I submit an issue it asks if a design is needed. I did say yes. That should address how we would reasonably ascertain if it's VIX or not.

Let's not over think this.

Message ID: @.***>

arnoldnipper commented 2 months ago

As I recall, the solution was to require a facility for the IX, with easy to click options (as dummy Fac objects) including Virtual.

Still, there are IXes which are real IXes which do not disclose any facility. This virtual IX discussion does not lead us anywhere

martinhannigan commented 2 months ago

Can you give an example of “real” IX without a facility? I don’t know how that would be possible.

On Sun, Feb 25, 2024 at 12:24 Arnold Nipper @.***> wrote:

As I recall, the solution was to require a facility for the IX, with easy to click options (as dummy Fac objects) including Virtual.

Still, there are IXes which are real IXes which do not disclose any facility. This virtual IX discussion does not lead us anywhere

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1557#issuecomment-1963006076, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQSGIK3L7QKSGFJEXDDYVNXVXAVCNFSM6AAAAABDXJGZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRTGAYDMMBXGY . You are receiving this because you authored the thread.Message ID: @.***>

arnoldnipper commented 2 months ago

Can you give an example of “real” IX without a facility? I don’t know how that would be possible.

Read carefully ... I was saying that atm there are "real" facilities in PeeringDB which didn't expose any facilities. I was not saying that they are in no facility. And there might also be IXes where you can connect to. However, they are not in a facility. I.e. you can't rent space there, but terminate only your connection to the IX

martinhannigan commented 2 months ago

On Tue, Feb 27, 2024 at 11:26 AM Arnold Nipper @.***> wrote:

Can you give an example of “real” IX without a facility? I don’t know how that would be possible.

Read carefully ... I was saying that atm there are "real" facilities in PeeringDB which didn't expose any facilities. I was not saying that they are in no facility. And there might also be IXes where you can connect to. However, they are not in a facility. I.e. you can't rent space there, but terminate only your connection to the IX

Perhaps the issue is better defined as "non facility IX" and flagged. Actually makes the issue stronger with more utility.

Message ID: @.***>

arnoldnipper commented 2 months ago

Perhaps the issue is better defined as "non facility IX" and flagged.

Who should flag that? And you already easily see when an IX has no facility listed ... for whatever reason ...

martinhannigan commented 2 months ago

On Wed, Feb 28, 2024 at 00:53 Arnold Nipper @.***> wrote:

Perhaps the issue is better defined as "non facility IX" and flagged.

easily see when an IX has no facility listed ...

How does a user flag that in a search or exports?

arnoldnipper commented 2 months ago

How does a user flag that in a search or exports?

E.g. 

curl -sG https://www.peeringdb.com/api/ix?fac_count=0
martinhannigan commented 2 months ago

Thats not via the UI.

arnoldnipper commented 2 months ago

Thats not via the UI.

That's true. While we decided that GUI and API have the same fields, the API is more powerful. And IMO it doesn't make sense to overload the GUI

grizz commented 2 months ago

As I recall, the solution was to require a facility for the IX, with easy to click options (as dummy Fac objects) including Virtual.

Still, there are IXes which are real IXes which do not disclose any facility. This virtual IX discussion does not lead us anywhere

The solution we discussed also included a dummy Fac object of "not disclosed" -- which I think would also work for "not in PDB" and solve that.

martinhannigan commented 2 months ago

But feature parity and equity? PDB should be easy to use for everyone.

I don't know that adding some options to export are overloading.

On Thu, Feb 29, 2024 at 12:58 Arnold Nipper @.***> wrote:

Thats not via the UI.

That's true. While we decided that GUI and API have the same fields, the API is more powerful. And IMO it doesn't make sense to overload the GUI

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1557#issuecomment-1971667145, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQUPF74322OQ5NGVKITYV5V45AVCNFSM6AAAAABDXJGZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZRGY3DOMJUGU . You are receiving this because you authored the thread.Message ID: @.***>

jackcarrozzo commented 2 months ago

Seeking some clarity-

cc @job @martinhannigan

job commented 2 months ago

Seeking some clarity-

  • Are there existing virtual IXs passing real traffic, or is this more along the lines of personal/test/play configs?

What's play for one might be real for another - very subjective :-)

  • What is a reasonable definition of "virtual IX" here- does it include situations where one IX's reach is extended via real but non-IX-controlled paths, or solely tunnel connections?

It is challenging to come up with a useful definition: there are a ton of large IXPs which are reached via non-IX-controlled tunnels (usally, MPLS or VXLAN, also known as "remote peering"). Whenever folks exchange Internet traffic, who is PeeringDB to judge how exactly it is transported?

  • Are there any cases where an IX might not be "virtual", but doesn't have a facility listed? Or inversely, IXs that are most certainly "virtual"/tunneled/other but would be incorrectly identified as "real" by way of listing a facility?

All permutations seem to exist, and no harm seems to come from the diversity of the ecosystem. A virtual selector seems to vague to me, because so much of Internet infrastructure is virtual to some degree (a vlan, a pseudo-wire, etc).

Users who are not interested in a given IXP will just ignore that IXP, whatever the reason.

jackcarrozzo commented 2 months ago

@martinhannigan, as the ticket opener, can you describe what part of your use case isn't sufficiently covered using the lack of facility as your "flag", or what the use case is that would be better served by having a separate object field / virtual facility / etc? Is it for easy use as a search predicate?

job commented 2 months ago

I think the ticket at hand relates to the following other tickets:

https://github.com/peeringdb/peeringdb/issues/992 https://github.com/peeringdb/peeringdb/issues/1236

I think PDB needs to aspire to be consistent and neutral. Because of the aforementioned, I suggest to imagine what would happen if PDB offers subjective selectors. Such selectors seem to facilitate separation of so-called "virtual" from "the rest" ... in an entirely digital world) and this has proven to be challenging so far, thus such selectors meaning nothing.

An IXP's "virtuality" probably isn't a binary state: one could imagine upcoming or diminishing IXP offering "tunnels", or "virtual cross-connects", or whatever those are technically to try to get more traction; in addition to fiber optical or electrical interconnection - perhaps the IXP offers service via partners who use Virtual LAN layer-2 switches to distribute... ?

OP talks about 'the true definition' in post 1, and later on seems to suggest definition is out of scope - this to me seem self-contradictory, but then my interpretation of it being self-contradictory would align with my observation that this concept might be problematic to support subjective selectors in search queries - because of lack of perspective on common denominators.

martinhannigan commented 2 months ago

Search, less probing(cost) of API, less code, more transportable data, easy visual indicator when drilling down in the UI, etc.

Not all users are sophisticated as many of us to code it or know it by looking at it. Not all systems can use the API. It also takes the angst off the table.

I can see regular probing of this data independent of search for a physical IX for various research purposes.

On Wed, Mar 13, 2024 at 22:32 Jack Carrozzo @.***> wrote:

@martinhannigan https://github.com/martinhannigan, as the ticket opener, can you describe what part of your use case isn't sufficiently covered using the lack of facility as your "flag", or what the use case is that would be better served by having a separate object field / virtual facility / etc? Is it for easy use as a search predicate?

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1557#issuecomment-1996283634, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQVJYDPGXCTSNB65KSTYYED4PAVCNFSM6AAAAABDXJGZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJWGI4DGNRTGQ . You are receiving this because you were mentioned.Message ID: @.***>

martinhannigan commented 2 months ago

We’re looking at it from two angles. Yours is political. A fast, easy, accurate simple way to know what we’re dealing with and know what we’re interconnecting with seems like a fair compromise to allowing them onto PDB in the first place.

Warm regards,

-M<

On Wed, Mar 13, 2024 at 23:04 Job Snijders @.***> wrote:

I think the ticket at hand relates to the following other tickets:

992 https://github.com/peeringdb/peeringdb/issues/992

1236 https://github.com/peeringdb/peeringdb/issues/1236

I think PDB needs to aspire to be consistent and neutral. Because of the aforementioned, I suggest to imagine what would happen if PDB offers subjective selectors. Such selectors seem to facilitate separation of so-called "virtual" from "the rest" ... in an entirely digital world) and this has proven to be challenging so far, thus such selectors meaning nothing.

An IXP's "virtuality" probably isn't a binary state: one could imagine upcoming or diminishing IXP offering "tunnels", or "virtual cross-connects", or whatever those are technically to try to get more traction; in addition to fiber optical or electrical interconnection - perhaps the IXP offers service via partners who use Virtual LAN layer-2 switches to distribute... ?

OP talks about 'the true definition' in post 1, and later on seems to suggest definition is out of scope https://github.com/peeringdb/peeringdb/issues/1557#issuecomment-1961938186

  • this to me seem self-contradictory, but then my interpretation of it being self-contradictory would align with my observation that this concept might be problematic to support subjective selectors in search queries - because of lack of perspective on common denominators.

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1557#issuecomment-1996305677, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQT6QRURZ33MF7733BLYYEHTXAVCNFSM6AAAAABDXJGZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJWGMYDKNRXG4 . You are receiving this because you were mentioned.Message ID: @.***>

job commented 2 months ago

Who is “them”, Martin?

arnoldnipper commented 2 months ago

We can't tell the difference between a virtual IX or a physically present IX without a ton of effort.

Why then waste time and effort?

martinhannigan commented 2 months ago

On Thu, Mar 14, 2024 at 17:37 Arnold Nipper @.***> wrote:

We can't tell the difference between a virtual IX or a physically present IX without a ton of effort.

Why then waste time and effort?

The value of the results and a better product.

Yes, DE-CIX will be flagged in some of these but that seems to also be an accurate result.

Message ID: @.***>

jackcarrozzo commented 1 month ago

PC call: internally generated "has_no_facilities" flag that ,makes it easy to find "virtuality" via api, for objs with no fac listed?

arnoldnipper commented 1 month ago

This would be the same as fac_count == 0. So why adding redundant information?

martinhannigan commented 1 month ago

To add more color, this is an automated mark, not an optional self-directed flag.

On Thu, Apr 4, 2024 at 12:08 PM Jack Carrozzo @.***> wrote:

PC call: internally generated "has_no_facilities" flag that ,makes it easy to find "virtuality" via api, for objs with no fac listed?

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1557#issuecomment-2037626171, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQWZ77CWRTWAMQNSWYTY3V3HDAVCNFSM6AAAAABDXJGZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZXGYZDMMJXGE . You are receiving this because you were mentioned.Message ID: @.***>

arnoldnipper commented 1 month ago

fac_count is a read-only, system generated value. I.e.

martinhannigan commented 1 month ago

A visual flag is what was discussed as well as a flag for automation to reduce queries (cost) and answer very specific questions.

Are you objecting to whats already usable for the UI?

On Fri, Apr 5, 2024 at 20:54 Arnold Nipper @.***> wrote:

fac_count is a read-only, system generated value. I.e.

  • has_no_facilities == true <==> fac_count == 0
  • has_no_facilities== false <==> fac_count > 0

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1557#issuecomment-2040834710, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQW4HT4FZ67VPS4D2QLY35BUPAVCNFSM6AAAAABDXJGZSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBQHAZTINZRGA . You are receiving this because you were mentioned.Message ID: @.***>

arnoldnipper commented 1 month ago

Again, there is no need adding a flag for automation as this information is already there. On the other hand, saying that every IX which does not have a facility is a virtual IX, clearly is wrong. I've named a lot of IXes which are so-called physical IXes but don't have a facility associated.

If we want to flag those IXes in the GUI we can do, but should not call them "virtual IXes"

But more important is what @job said: Wasn’t this discussed a number of times before, with the main issue being that it’s hard to define what a “virtual” IX is?