Closed mustangthz closed 2 years ago
job
commented
3 years ago I would prefer to solve this problem differently, because there are quite some 'virtual' (whatever the word means :smile:) IXPs that have a hybrid presence and permit both fiber and tunnels/pseudowires.
I'll write up a proposal to tackle this issue and improve the user experience in a different way
grizz
commented
3 years ago This was solved on a PDBPC phone call / mailing list thread, we should track it down an implement it :)
mustangthz
commented
3 years ago This was solved on a PDBPC phone call / mailing list thread, we should track it down an implement it :)
I'd love to get this solved on two tracks. One to allow the flag to be set, and one to allow advanced filtering in responses. Both have strong pros and cons, both would be useful.
netravnen
commented
3 years ago IMO, having a flag for 100 % virtual IXP could be useful.
E.g.
I agree each approach has its pros and cons. Depending on your perspective. Letting IXP's (or AC) set a flag on the ix-level could be useful to users. But if it is the "correct" long-term solution... I have no clue to answer.
martinhannigan
commented
3 years ago IMHO
Not our job to decide whats best or worst, just to ensure all are presented fairly and with enough detail to allow interpretations.
+1 with hybrid flag
On Sat, Jun 26, 2021 at 20:11 netravnen @.***> wrote:
IMO, having a flag for 100 % virtual IXP could be useful.
E.g.
- fully virtual ixp
- hybrid ixp (both accepting virtual and physical connections)
- 'traditional' ixp (the default, only physical connections)
I agree each approach has its pros and cons. Depending on your perspective. Letting IXP's (or AC) set a flag on the ix-level could be useful to users. But if it is the "correct" long-term solution... I have no clue to answer.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/992#issuecomment-869077531, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQSBLNFE3KH4TZJE7Q3TUZUB3ANCNFSM47EK6WZQ .
job
commented
3 years ago I'm skeptical these words "virtual", "hybrid" mean the same things to different people. Even "underlay" or "overlay" is challenging, as many IXPs nowadays have constructed their IX service as an "overlay" on a private BGP network. Another complication with these words is that to many people "virtual" and "remote peering" are synonymous, or perhaps "virtual" is everything Internet related; and since almost all IXPs offer access both as direct customer or via resellers... these self-classifiers might end up being interpreted differently than intended, which in turn could harm the ecosystem.
In the PC call today the idea was brought up to reach out to some self-described "virtual" IXPs and ask them for feedback. Let's wait for some more information.
martinhannigan
commented
3 years ago How much simpler could it be that physical, virtual or both?
On Thu, Jul 1, 2021 at 13:21 Job Snijders @.***> wrote:
I'm skeptical these words "virtual", "hybrid" mean the same things to different people. Even "underlay" or "overlay" is challenging, as many IXPs nowadays have constructed their IX service as an "overlay" on a private BGP network. Another complication with these words is that to many people "virtual" and "remote peering" are synonymous, or perhaps "virtual" is everything Internet related; and since almost all IXPs offer access both as direct customer or via resellers... these self-classifiers might end up being interpreted differently than intended, which in turn could harm the ecosystem.
In the PC call today the idea was brought up to reach out to some self-described "virtual" IXPs and ask them for feedback. Let's wait for some more information.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/992#issuecomment-872421063, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQWQG3DEG65WWMNAK2TTVSPZ5ANCNFSM47EK6WZQ .
MasterWayZ
commented
3 years ago What you could also do is make a dropdown of some sort. Virtual IX: "Yes", "No" or "Hybrid" (=both) And possibly implement a way to search PeeringDB for VIXes (so the dropdown being set to "Yes or "Hybrid").
job
commented
3 years ago @MasterWayZ would a self classifier such as production and experimental be useful instead of using the word 'virtual', which is already used so much in internet language.
MasterWayZ
commented
3 years ago @job Well, the point of 'virtual' is to show that it is not an exchange with a physical presence where you can connect. But instead they use tunnels (hence the virtual part). The VIXes I'm familiar with are for educational purposes for example.
job
commented
3 years ago The word "virtual" means different things to different people, consider that some IXPs deliver packets VLAN tagged (virtual lan).
Capturing the essence of this type of operation based on its purpose rather than its execution might prove to be valuable.
How about we copy "Network Type" list into a newly defined "IX Type" list.
It makes sense to me that an IX might want to classify itself a enterprise or nonprofit or research etc. The only types that doesn't make sense to copy is "Route Server" and "Route Collector".
Would the group consider upgrading this from a " checkbox" to a "multiple-choice" ?
job
commented
3 years ago Proposal, the following dropdown menu for "IX Types"
IX Types:
mwtr
commented
3 years ago Proposal is big help for us. But network architectures and types of organizations are mixing in proposal. And I would like to know definition of Remote and Cloud. In my understanding, remote means deployment by tunnel/pseudowire. Could you please let us know an example of Cloud as a IX type...? Thank you.
martinhannigan
commented
3 years ago Good work. Feels too wide in scope. Physical, Virtual or Both is very clear for all the types listed below. Thanks for this.
Renote is interesting. Isn't remote really an application?
Tks
-M<
On Fri, Jul 9, 2021 at 17:09 Job Snijders @.***> wrote:
Proposal, the following dropdown menu for "IX Types"
IX Types:
- Not Disclosed
- Cloud
- Enterprise
- Educational/Research
- Non-Profit
- Government
- Remote
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/992#issuecomment-877457458, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQV726TAZSX4CSYKZ3TTW5QP3ANCNFSM47EK6WZQ .
netravnen
commented
3 years ago Does the PeeringDB codebase support feature flags?
E.g. for testing features in the beta environment but not enable the features in prod until agreed stable and user-friendly by a vote of PeeringDB staff and community members?
Reasoning: This has the potential to make it easier to solicit feedback for e.g. this ongoing discussion of how to represent Virtual/Remote IX's in PeeringDB from a wider user-base.
grizz
commented
3 years ago Side Question
Does the PeeringDB codebase support feature flags?
E.g. for testing features in the beta environment but not enable the features in prod until agreed stable and user-friendly by a vote of PeeringDB staff and community members?
Sure, and I know we've done that before but I can't think of an example. :)
I'm not sure that's the best idea in this case, since we could accomplish similar at a lot less time spent by mocking up screenshots, but it's certainly possible if consensus is to do it.
leovegoda
commented
2 years ago The Product Committee has decided to close this issue. There was no agreement on the concept and the issue has not been discussed for six months or longer.
as44980
commented
2 years ago This was solved on a PDBPC phone call / mailing list thread, we should track it down an implement it :)
The Product Committee has decided to close this issue. There was no agreement on the concept and the issue has not been discussed for six months or longer.
Agaim, was there "no agreement on the concept " or was this "solved on a PDBPC phone call / mailing list thread"... ?
I assume it cannot be both, and if its the latter then that suggests a lack of transparency in particular with the most recent round of issues which have been closed on the basis that "the issue has not been discussed for six months or longer" :(
mustangthz
commented
2 years ago This needs to be solved.
On Jun 13, 2022, at 5:16 AM, as44980 @.***> wrote:
This was solved on a PDBPC phone call / mailing list thread, we should track it down an implement it :)
Agaim, was there "no agreement on the concept " or was this "solved on a PDBPC phone call / mailing list thread"... ?
I assume it cannot be both, and if its the latter then that suggests a lack of transparency in particular with the most recent round of issues which have been closed on the basis that "he issue has not been discussed for six months or longer." :(
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
job
commented
2 years ago We seem to somewhat be going in circles on this topic. What problem exactly needs to be addressed?
On Mon, 13 Jun 2022 at 13:09, mustangthz @.***> wrote:
This needs to be solved.
On Jun 13, 2022, at 5:16 AM, as44980 @.***> wrote:
This was solved on a PDBPC phone call / mailing list thread, we should track it down an implement it :)
Agaim, was there "no agreement on the concept " or was this "solved on a PDBPC phone call / mailing list thread"... ?
I assume it cannot be both, and if its the latter then that suggests a lack of transparency in particular with the most recent round of issues which have been closed on the basis that "he issue has not been discussed for six months or longer." :(
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/992#issuecomment-1153729473, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABFRWGCHT4FKPWWGW6VU2DVO4CHFANCNFSM47EK6WZQ . You are receiving this because you were mentioned.Message ID: @.***>
mustangthz
commented
2 years ago That the community would like a method to distinguish between tunnel and non-tunnel based IXs.
On Jun 13, 2022, at 6:15 AM, Job Snijders @.***> wrote:
We seem to somewhat be going in circles on this topic. What problem exactly needs to be addressed?
On Mon, 13 Jun 2022 at 13:09, mustangthz @.***> wrote:
This needs to be solved.
On Jun 13, 2022, at 5:16 AM, as44980 @.***> wrote:
This was solved on a PDBPC phone call / mailing list thread, we should track it down an implement it :)
Agaim, was there "no agreement on the concept " or was this "solved on a PDBPC phone call / mailing list thread"... ?
I assume it cannot be both, and if its the latter then that suggests a lack of transparency in particular with the most recent round of issues which have been closed on the basis that "he issue has not been discussed for six months or longer." :(
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/992#issuecomment-1153729473, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABFRWGCHT4FKPWWGW6VU2DVO4CHFANCNFSM47EK6WZQ . You are receiving this because you were mentioned.Message ID: @.***>
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
job
commented
2 years ago Who decides what is and what isn’t a “tunnel IX”?
What definition is used that can be verified?
Aren’t there other approaches we can come up with to resolve the needs of users searching for IXPs?
On Mon, 13 Jun 2022 at 13:17, mustangthz @.***> wrote:
That the community would like a method to distinguish between tunnel and non-tunnel based IXs.
On Jun 13, 2022, at 6:15 AM, Job Snijders @.***> wrote:
We seem to somewhat be going in circles on this topic. What problem exactly needs to be addressed?
On Mon, 13 Jun 2022 at 13:09, mustangthz @.***> wrote:
This needs to be solved.
On Jun 13, 2022, at 5:16 AM, as44980 @.***> wrote:
This was solved on a PDBPC phone call / mailing list thread, we should track it down an implement it :)
Agaim, was there "no agreement on the concept " or was this "solved on a PDBPC phone call / mailing list thread"... ?
I assume it cannot be both, and if its the latter then that suggests a lack of transparency in particular with the most recent round of issues which have been closed on the basis that "he issue has not been discussed for six months or longer." :(
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
— Reply to this email directly, view it on GitHub < https://github.com/peeringdb/peeringdb/issues/992#issuecomment-1153729473 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AABFRWGCHT4FKPWWGW6VU2DVO4CHFANCNFSM47EK6WZQ
. You are receiving this because you were mentioned.Message ID: @.***>
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/992#issuecomment-1153736654, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABFRWG4J7G7NPFRGQUOTITVO4DDTANCNFSM47EK6WZQ . You are receiving this because you were mentioned.Message ID: @.***>
mustangthz
commented
2 years ago It’s easy. Do you allow tunnels check box.
Move on
On Jun 13, 2022, at 6:21 AM, Job Snijders @.***> wrote:
Who decides what is and what isn’t a “tunnel IX”?
What definition is used that can be verified?
Aren’t there other approaches we can come up with to resolve the needs of users searching for IXPs?
On Mon, 13 Jun 2022 at 13:17, mustangthz @.***> wrote:
That the community would like a method to distinguish between tunnel and non-tunnel based IXs.
On Jun 13, 2022, at 6:15 AM, Job Snijders @.***> wrote:
We seem to somewhat be going in circles on this topic. What problem exactly needs to be addressed?
On Mon, 13 Jun 2022 at 13:09, mustangthz @.***> wrote:
This needs to be solved.
On Jun 13, 2022, at 5:16 AM, as44980 @.***> wrote:
This was solved on a PDBPC phone call / mailing list thread, we should track it down an implement it :)
Agaim, was there "no agreement on the concept " or was this "solved on a PDBPC phone call / mailing list thread"... ?
I assume it cannot be both, and if its the latter then that suggests a lack of transparency in particular with the most recent round of issues which have been closed on the basis that "he issue has not been discussed for six months or longer." :(
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
— Reply to this email directly, view it on GitHub < https://github.com/peeringdb/peeringdb/issues/992#issuecomment-1153729473 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AABFRWGCHT4FKPWWGW6VU2DVO4CHFANCNFSM47EK6WZQ
. You are receiving this because you were mentioned.Message ID: @.***>
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/992#issuecomment-1153736654, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABFRWG4J7G7NPFRGQUOTITVO4DDTANCNFSM47EK6WZQ . You are receiving this because you were mentioned.Message ID: @.***>
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
job
commented
2 years ago Ah, think I see what you mean.
You suggest that IX object owners optionally indicate whether their IX accepts connections via tunnel. This is not a checkbox checked by AdminComm (even at the request of net object owners).
Then in the search tool you can search for IXs that have the checkbox set.
Correct?
Do you have a suggestion for what could be displayed in the mouseover hint? Maybe the following?
“Tunnels are connections that run over GRE, IPIP, WireGuard, or similar”
mustangthz
commented
2 years ago Correct,
The IX owners would check the box that they accept connections via tunnels.
Your description is good, but I’d be open to suggestions on the final tool tip/mouse over.
The goal would be to include/exclude search based on that boxes check.
Chris
On Jun 13, 2022, at 9:03 AM, Job Snijders @.***> wrote:
Ah, think I see what you mean.
You suggest that IX object owners optionally indicate whether their IX accepts connections via tunnel. This is not a checkbox checked by AdminComm (even at the request of net object owners).
Then in the search tool you can search for IXs that have the checkbox set.
Correct?
Do you have a suggestion for what could be displayed in the mouseover hint? Maybe the following?
“Tunnels are connections that run over GRE, IPIP, WireGuard, or similar” — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
martinhannigan
commented
2 years ago +1
The tooltip should be brainless so that the users who don't understand, do.
'A virtualIX is typically not local to the majority of its users. You should expect a high level of latency. It may also not be clear who is running the IX'
The last bit is important. Who are these people who are running them and using them? Should I not have some (national) security concerns?
Thanks
On Mon, Jun 13, 2022 at 9:16 AM mustangthz @.***> wrote:
Correct,
The IX owners would check the box that they accept connections via tunnels.
Your description is good, but I’d be open to suggestions on the final tool tip/mouse over.
The goal would be to include/exclude search based on that boxes check.
Chris
On Jun 13, 2022, at 9:03 AM, Job Snijders @.***> wrote:
Ah, think I see what you mean.
You suggest that IX object owners optionally indicate whether their IX accepts connections via tunnel. This is not a checkbox checked by AdminComm (even at the request of net object owners).
Then in the search tool you can search for IXs that have the checkbox set.
Correct?
Do you have a suggestion for what could be displayed in the mouseover hint? Maybe the following?
“Tunnels are connections that run over GRE, IPIP, WireGuard, or similar” — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/992#issuecomment-1153901575, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQWC3DKTYLL5PFHHZCTVO4YBTANCNFSM47EK6WZQ . You are receiving this because you commented.Message ID: @.***>
Hello,
With the proliferation of new VirtualIX's that are being added to PeeringDB, I'd like to request a checkbox that the VirtualIX's can set, or other users can request be set by the AC.
Criteria: VirtualIX's have no facility to accept physical connections to the IX. Flag should be set to minimize confusion between Physical IXs and Virtual IXs.