Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Virtual Facilities and interconnect providers #1236

Closed
terafirmanz opened this issue Sep 9, 2022 · 5 comments
Closed

Virtual Facilities and interconnect providers #1236

terafirmanz opened this issue Sep 9, 2022 · 5 comments
Milestone

Comments

@terafirmanz
Copy link

Is your feature request related to a problem? Please describe.
First off I use Megaport here as an example but I am not affiliated with them at all.

With modern networking, it is no longer a given that interconnection is based on physically being in a facility. We can now buy presence on a network like Megaport that gives us virtual presence in many facilities.

It would be beneficial if I could add "fabric" providers (name used to not confuse it with network) the same way I can add facilities. Then anyone on the same "fabric" can meet me or request an interconnection.

Nothing in this request is to do with private peering or BGP interconnection uploads simply the ability to show others what methods they have to connect with us be it a facility we are both in or a L2 service we are both on.

I realise that companies like Megaport list their facilities on here but that requires manually cross-checking my and your facilities against their list.

What is the impact?
A new type would be added similar to facility but with less attributes.

Are there security concerns?
No

Are there privacy concerns?
No
Describe the solution you'd like
As above a new type of entity added similar to facility but with less metadata and maybe an option for network operators to create public "fabrics".

Do you think this feature will require a formal design?
yes

Describe alternatives you've considered
Users manually check for providers known to offer interconnection and if they are in both facilities side A and side B are in. The can be hard as at times this information might not be public e.g. I have a Megaport but am not on their peering).

Could this feature request need support from the Admin Committee?
What providers are allowed onto this list may have to be via approval to stop providers appearing capable but not actually able to deliver.

What is the proposed priority?
not urgent

Provide a rationale for any/all of the above
It greatly helps provide two users trying to interconnect the ability to see quickly what options without having to run off a list of interconnect providers or search for any they may not know of.

@arnoldnipper
Copy link
Contributor

I realise that companies like Megaport list their facilities on here but that requires manually cross-checking my and your facilities against their list.

If it's only because of that: we provide an API :)

@terafirmanz
Copy link
Author

terafirmanz commented Sep 10, 2022

If it's only because of that: we provide an API :)

Yes this is what we do but this requires knowledge beforehand of:
a) what providers offer this service - we can't all track who offers what globally
b) the other party has a connection with a common provider of this type of service
c) the other end has an interconnection with the provider - this may not be visible in PDB if they have a connection but don't use it for BGP peering

If you are just trying to connect to another network and want to know what options you have this information would save considerable time.

@grizz grizz added this to the 1 Decide milestone Sep 30, 2022
@martinhannigan
Copy link

This sounds a lot like remote peering. Im not certain defining "virtual facilities" does anything but obfuscate the true presence of an AS. If the performance isn't good enough for someone in say, Boston, to peer with you on $somePort while you're in Idaho, obfuscating it with a "virtual" indicator would seem to complication performance decisions. No?

@peterhelmenstine
Copy link

This sounds like the carrier object request so this may be a duplicate request?

@leovegoda
Copy link
Contributor

This was discussed in today's @peeringdb/pc meeting. It looks like a strong overlap with #909 so we'll close this issue while we continue work on that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants