Peeringdb: Add location of Physical IX-Port & Router Port

[JGrondel]

I would like the PeeringDB UI to reflect the location of the physical IX port. For most use cases a link to the facility would suffice.

The use cases where this would be relevant:
When setting up bilateral sessions over an IX you would like to keep your traffic as local as possible. Especially when peering with a network that has multiple ports on an exchange you would want to minimize latency and improve on resilience. One would normally prefer to set up sessions in the same facility, over sessions in the same metro, country or even cross border sessions.

Currently most exchanges offer a member list in the standardized euro-ix json-format where the requested information is optionally listed. Unfortunately, this format is not meant to be read and used by a human. Also it should be noted that some networks have automated processes based on PeeringDB and not on the Euro-ix format.

I do see several ways the information could be presented in the GUI and/or the API.
Information could be added to the “Peers at this exchange point” on the IX pages and/or “Public Peering Exchange Points” on the network's page.
One could even argue for complete new pages per port where more relevant information could be shown.

Note: Although not part of this request this may also be the time to list the location of the router connected to the IX-port. This router may be in the same facility as the switch port but could also be on another continent. Listing the router’s location would give an insight in remote-IX participation.)

[job]

I support this proposal, but only if we also allow for the "location of the router connected to the IX-port" to be specified.

Some suggestions for clarification:

Location of Physical IX-Port: the facility in which the port connected to the IX fabric is located. This means that when an "network" user indicates they are connected to an IXP, they should be presented with a drop-down menu which shows only the facilities in which the specified IX is present. This information potentially could be pre-filled with information from the euroix json data feeds.

Location of the Router port: the facility in which the router port on the "network" side is located. This means that when an "network" user indicates they are connected to an IXP, they should be presented with a drop-down menu which shows only the facilities in which the network themselves is present.

In practical terms - NTT might have a router in "InterXion Science Park", which is connected to an AMS-IX port located in NIKHEF. The "IX port" would be in NIKHEF, the router port would be in Interxion.

If we make a sort of wizard for people to quickly add ports, we can hopefully make the wizard clever by asking the questions in such a way that we can skip over redundant questions (in case the Router port and IX port are in the same facility).

[job]

Further more - if we accept the notion of in more detail listing where the IX port is and where the Router port is, the user interface could leverage a simple haversine calculation to help users analyse the data they are looking for (for instance, we could maybe have a sorting button so you can sort on distance, or a search engine filter to list results that are closer by than X)

[arnoldnipper]

+1 ... very much like @job 's ideas

[kay23]

I support @job 's proposal on how to implement it by associating the Physical IX-Port and the location of the Router port.

[fkorsback]

+1

I would definately like to see a flag or field that clearly shows in which metropolitian-area the ip-adress im about to peer with is currently in.

[schiederme]

If would be nice, if networks can add a tag for remote peering.

[grizz]

+1 from me, great ideas! Off the top of my head, what do we do about private facilities? Could allow for manually entering long / lat? or Just leave it for now and people can pick the facility closest to where they're at?

[arnoldnipper]

What do you mean by "private facilities", @grizz? I guess this is something different then "Private Peering Facilities". Right?

Currently, we require that facilities to be listed have to offer service to the public. However, when introducing this feature it would also make sense to list those _private facilities_.

[fkorsback]

+1 from me, great ideas! Off the top of my head, what do we do about private facilities? Could allow for manually entering long / lat? or Just leave it for now and people can pick the facility closest to where they're at?

Thats why i was thinking instead of flagging which facility the "location of the port connected to the IX that holds the IXLAN IP-Adress" it could be marked with "closest city" instead of facility. Cause in reality what we (the people peering on IX:es) care about is the proximity to the peer, not really if that network is coming through facility1 or facility2 in the same city. But if the peer comes in from south-africa to for example amsterdam, its important to know.

So to avoid pitfalls such as unregistered facilities, private facilties, secret facilities (for example this happens quite alot in Sweden) maybe a geographical affiliation is good enough?

[arnoldnipper]

So what about either fac_id or (longitude, latitude)?

[mahtin]

@arnoldnipper - it should always be a fac_id because you want all locations to have the full compliment of attributes independent of usage. A fac_id maps into the info in /api/fac and that's very useful.

For a small IX there should be a data structure (or documentation) that maps an IX's fac_id to be the same as the physical IX port fac_id.

Oh; so what happens when a network long-hauls it's port from the IX's fac_id to some other datacenter fac_id. That should not mean the IX is listed within that other datacenter. There should be an explicit understanding that only the IX's fac_id controls location vs. the networks fac_id.

BTW: If you go read #515, you would see that these Virtual-IX's don't have a valid main fac_id and hence, if we allow them, then the networks/members/customers all need an explicit fac_id per entry. So maybe #515 defines this need!

[arnoldnipper]

BTW: If you go read #515, you would see that these Virtual-IX's don't have a valid main fac_id and hence, if we allow them, then the networks/members/customers all need an explicit fac_id per entry. So maybe #515 defines this need!

@mahtin, there are also a couple of so-called Internet-backbone-interconnection IXs which don't have any ixfac records. Otoh there are so-called Virtual-IXs which have fac_id records.

Just to give you an idea. We have 725 ix, but only 497 have at least one ixfac record associated. Unlikely that we already have 228 so-called Virtual-IXs.

[arnoldnipper]

it should always be a fac_id because you want all locations to have the full compliment of attributes independent of usage

@mahtin, not all networks are in a location which has a fac_id. Hence (longitude, latitude) would be needed.

[mahtin]

@mahtin, not all networks are in a location which has a fac_id. Hence (longitude, latitude) would be needed.

That's being damn lazy. You either have facilities or you don't exist. Period. Don't mess up a database with random overlapping data fields just because it's the easy thing to do. If a network (or IX or IX remote port) decides it's in some other place, then provide a way to create a facility (and hence fac_id). At least then, there's consistency and a way-forward to allocate ownership of facilities.

Just to give you an idea. We have 725 ix, but only 497 have at least one ixfac record associated. Unlikely that we already have 228 so-called Virtual-IXs.

Indeed. It actually sounds like we have IXs that need some serious review so that missing data is created.

[grizz]

We have an easy way to create a facility: https://www.peeringdb.com/suggest/fac

From comments, and review, I think forcing fac_id is a good idea, if it's a secret private facility on the Router Location side, it's such an edge case, it probably doesn't matter. Adding the two fields to netixlan would be beneficial to most users.

1. They could either pick the nearest facility, but then it would show them present in a facility they may not be

2. We could allow "Router Location" to be null for networks

3. We could add "private" to the Facility object, let them set a lat/long, and only allow them to pick it.

I'm leaning towards 2.

[arnoldnipper]

@grizz, all of what you propose does not really make sense to me. Only because you have a hammer not everything has to be a nail.

Why are we leaned towards forcing fac_id? Only because we need (longitude, latitude). Right? So why not using either of this?

[grizz]

Because in 99+% of the cases, people are going to be connected at a facility we already have, so it would be a lot easier for them to just select it from a drop down.

It forces both networks and IXPs to keep their data updated.

Additionally, it keeps the code, API, and UI clean and easy. If it's required, imagine explaining to people that they had to go look at the facility they're connected to and copy paste long/lat into the fields.

And as @mahtin said:

You either have facilities or you don't exist. Period.

Which I fully support, with the exception of "None" if you don't want to disclose it or are virtual :)

[mahtin]

Which I fully support, with the exception of "None" if you don't want to disclose it or are virtual :)

Yes, I'm a +1 on "None" (as described by @grizz noted as option 2 above).

[arnoldnipper]

Additionally, it keeps the code, API, and UI clean and easy. If it's required, imagine explaining to people that they had to go look at the facility they're connected to and copy paste long/lat into the fields.

Of course, each net or ix is in some building, but not necessarily in PDB fac. There might e.g. ix where you only can connect to via a carrier (i.e. remote connections).

And of course, I don't want anyone to copy-paste geolocation data. They only may have to provide these, if they are not located in a facility.

Let's do a proper modelling and not just use the hammer :)

[arnoldnipper]

What about

• adding new fields net_netfac_id (net endpoint) and net_ixfac_id (ix endpoint) to netixlan
• default for both is null
• net_netfac_id is the fac_id of a facility where net is. Hence a netfacrecord also should exist
• net_ixfac_id is the fac_id of a facility where ix is. Hence a ixfacrecord also should exist
• value is only settable by net

[mcmanuss8]

What about

• adding new fields net_netfac_id (net endpoint) and net_ixfac_id (ix endpoint) to netixlan

Maybe netfac_id and ixfac_id ? The extra net in the front could be confusing IMO.

• default for both is null
• net_netfac_id is the fac_id of a facility where net is. Hence a netfacrecord also should exist
• net_ixfac_id is the fac_id of a facility where ix is. Hence a ixfacrecord also should exist
• value is only settable by net

Seems good

[DenisKlimek]

+1 We support this too. Specially if you're connected to a IXP which is spreaded all over a country or even multiple countries.

[netravnen]

On Mon, 13 Jan 2020 at 13:03, Denis Klimek [e-mail] wrote:

+1 We support this too. Specially if you're connected to a IXP which is
spread all over a country or even multiple countries.

& with remote peering becoming more of a thing in recent years. (refer to
e.g. study published via the RIPE NCC in 2018,
https://labs.ripe.net/Members/vgiotsas/uncovering-remote-peering-at-internet-exchange-points
)

[vidister]

Maybe it's sufficient to provide the location of the IXP port and the latency from there to the peering Router.
That would be more useful for traffic engineering since the plain locations don't help much if you don't know which fiber path is being used. Also that would solve the problem of having to record all private locations which could be secret.

[job]

Maybe it's sufficient to provide the location of the IXP port and the latency from there to the peering Router.
That would be more useful for traffic engineering since the plain locations don't help much if you don't know which fiber path is being used. Also that would solve the problem of having to record all private locations which could be secret.

I think that further complicates things because it no longer depends on user contributed data, explicit involvement of the ixp, and a clear consensus on what route server where's measurement means what.

One can even argue that fiber paths can automatically be assumed in many locations given the abundance of KMZ files. "Private locations" in context of peeringdb, are not "private" but for "private peering". The word private means the opposite in our terminology in many cases funny enough.

I think having both IXP port and Router port is important

[arnoldnipper]

I think having both IXP port and Router port is important

Strong ACK. KISS ... from there anyone may build fancy tools.

[DenisKlimek]

What about using the data from the IXP itself which is very often in JSON available? Many IXPs are including the physical location of the connected switch to it.

Mit freundlichem Gruß
Stadtwerke Norderstedt

Denis Klimek

Carrier Manager & Professional Network Engineer
IP-Systemtechnik

Tel: +49 (0) 40 / 521 04 – 1049

[email protected][e-mail]
www.stadtwerke-norderstedt.dehttp://www.stadtwerke-norderstedt.de/

Von: Arnold Nipper [mailto:[email protected]]
Gesendet: Dienstag, 14. Januar 2020 01:07
An: peeringdb/peeringdb
Cc: Klimek, Denis; Comment
Betreff: Re: [peeringdb/peeringdb] Add location of Physical IX-Port & Router Port (#607)

I think having both IXP port and Router port is important

Strong ACK. KISS ... from there anyone may build fancy tools.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/peeringdb/peeringdb/issues/607?email_source=notifications&email_token=AG3MJYQNRFKW72W7IPXUMG3Q5T62TA5CNFSM4JZ6RYZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI2YYCQ#issuecomment-573934602, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AG3MJYT2SGQ7VLJNN26XZW3Q5T62TANCNFSM4JZ6RYZQ.

[JGrondel]

What about using the data from the IXP itself which is very often in JSON available? Many IXPs are including the physical location of the connected switch to it.

For the location of the IXP port this sounds reasonable for those networks that allow IXP updates.
Be aware that IXP's are not aware/do not list the location of the router.

Unfortunately naming of data centres is not always consistent. However, the IX-F Member List does allow to include a "pdb_facility_id" for data centres. If the localisation of the IXP port would (partially) be based on the .json scheme this could be used.

[martzuk]

I think having both IXP port and Router port is important

I agree, but I see a conflict in a few places. We're trying to show a physical attribute (well actually two), but we seem reluctant to enforce at minimum 1 facility, see #611.

IMHO the user should be able to select the port location as a drop down, populated by the facilities an IX lists on its entry. To cover the situation of it being an entirely (playground IX) we should have a "Virtual" facility in pdb (see #515). To cover the situation of a facility not being listed the IX can either ask the site operator to add it, or it can be suggested to pdb (https://peeringdb.com/suggest/fac). The user should then be able to select the router location by either selecting "same as port" or "remote".

This does the following:

• Makes it easy for a user to provide the information without copying/pasting lat/lon
• Keeps the data quality high
• Separates "real" (seems to be a subjective term) and "playground" IXPs without having to remove them

To echo what Martin says:

You either have facilities or you don't exist. Period.

However we want to encourage use of PeeringDB in BGP experimentation and the like, so the above feels it can accomodate both the use case of improving PeeringDB functionality and data quality without excluding said use case of playground IXPs (which seem to have ballooned as of late).

[arnoldnipper]

@martzuk there are also many non-playground ixes having no facility they are in. For whatever reason. We can't and probably don't want to force them to add one as one of the topmost paradigms of PeeringDB is that the user decides what to publish. Or not to publish.

[martzuk]

Then how do we expect people to list where a port/connection is, if it isn't anywhere?

[job]

I expect the listing to be optional

On Sat, Jan 25, 2020 at 00:45 Marty Strong [e-mail] wrote:

Then how do we expect people to list where a port/connection is, if it
isn't anywhere?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/peeringdb/peeringdb/issues/607?email_source=notifications&email_token=AABFRWAZFHKCGQQKZDIFKTTQ7MEILA5CNFSM4JZ6RYZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ3GJ2I#issuecomment-578184425,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABFRWAAHHEVFLTNDORBEHLQ7MEILANCNFSM4JZ6RYZQ
.

[arnoldnipper]

Then how do we expect people to list where a port/connection is, if it isn't anywhere?

@martzuk they may still list their end if the IX does not provide facility information. No?

[martzuk]

Not if the facility doesn't exist on peeringdb like you said.

there are also many non-playground ixes having no facility they are in.

If the facility is on peeringdb it's hardly a stretch to expect the ix to list it as a pop

[arnoldnipper]

Maybe I misunderstand this whole issue. For a connection to an ix (i.e. there is a netixlan object), there is an A-End (net) and a B-End (ix). For the A-End there should be a netfac object with net_id being the id of the net connected to the ix. And for the B-End there should be an ixfac object with ix_id being the id of the ix where the net is connected to. A-End should be selectable and specified by the net. B-End should be selectable and specified by the IX. This is my understanding of how it should work.

And whether an IX list a facility as a pop is up to the IX.

[job]

Dear all - I'm attempting to summarize what has been discussed so far infused with my perspective on what potential direction we can take here.

The netixlan object can be extended with two a_side and z_side attributes. The *_side attributes point to a fac_id. The network operator (net_id owner) can set the a_side attribute to whatever fac_id they are present in, the IX (ix_id owner) can set the z_side to whatever fac_id the IX is present in.

I'm sure the euro-ix json format can be used to help feed the z_side fac_id values, and the l3 network operator can either use the API or the web UI (via a pull down menu) to set the a_side.

Both a_side and z_side are entirely optional.

Data Ownership: IX owns z_side, Network operator owns a_side. If there is disputes conflicts the AC can handle them.

Thoughts?

[job]

To add: over time it is possible a network operator migrates the connection to a different datacenter via layer-2 or optical backhauling, then the network operator can update a_side to the new fac_id where according to them the netixlan connection is terminated in a router. This is user submitted data - if the network operator indicates that their LINX connection is terminated in Africa, so be it. That is up to them.

Similarly, an IX can migrate customers, an IX may accept the incoming cross connect in datacenter A, but in reality connect the cross connect to the layer-2 fabric in datacenter B. An IX might migrate customers from datacenter to datacenter through optical backhauling - again, that is up to the IX. They can set z_side to whatever they think is appropriate.

Both sides are user submitted data, and technology independent.

[kevin-nlix]

I agree with the approach regarding the ownership model; it makes a lot of sense taking into account the processes around these connections.

The only thing I'd change in your proposal are the column names; using ambiguous terminology like side leads to confusion and thus bugs. I suggest calling them net_fac and ix_fac, clearly indicating which part of the connection they belong to. The downside of this naming is that there's also the ixfac and netfac tables, so it can also be somewhat confusing as we're not going to reference those, hence the _ in between which you would not use when referencing those tables.

[job]

@kevin-nlix yeah... I picked A & Z side because that is terminology often found in describing interconnections in inter-company context, but I'm not married to any specific terms, though I think ix_fac vs ixfac will lead lots of confusion, because we don't really pronounce underscores _ in voice communication :-)

A classic example of unfortunate naming that continues to haunt us to this very day is that we have AS_SET in BGP protocol, AS-SET in IRR protocol, and asset as an English noun :-)

[arnoldnipper]

@kevin-nlix and @job: what about net_side and ix_side?

[kevin-nlix]

I could support that. At that point you're basically saying the Network/Internet Exchange side of the Public Peering Exchange Point. In the current data model the term side isn't really ambiguous; it shouldn't be that big of a deal for now. This is also a new scenario for the data model as this kind of connection between models hasn't been made before, so there's no right or wrong here.

Also, I was thinking about this over the weekend and I've always wondered why the connection between NetworkIXLan and Facility wasn't there yet. Is there any historical reason why this hasn't been implemented or is it just a case of 'never got around to it'? I suspect the latter, but in case of the former it's good to know about the considerations of the past.

[arnoldnipper]

Also, I was thinking about this over the weekend and I've always wondered why the connection between NetworkIXLan and Facility wasn't there yet

A simple relation between netixlan and fac does not make sense. That's the reason we now enhance the data model.

[as44980]

Data Ownership: IX owns z_side, Network operator owns a_side. If there is disputes conflicts the AC can handle them.

This concerns me as it would at least appear to dilute the "user submitted" data model, which if this was implimented would undermine the value of PeeringDB in my eyes :(

[arnoldnipper]

This concerns me as it would at least appear to dilute the "user submitted" data model, which if this was implimented would undermine the value of PeeringDB

Would you mind to explain, @as44980?

[as44980]

Would you mind to explain, @as44980?

Sure, based on..

the IX (ix_id owner) can set the z_side to whatever fac_id the IX is present in.

If the Network declines to set any value for the a_side (or sets this to the poposed value of "None"), but the IX is encouraged to list the z_side based on where they deliver the service, does this not risk "outing" the network as being present in or near to the z_side facility when they have decided not to share this information?

[as44980]

Of course, each net or ix is in some building, but not necessarily in PDB fac. There might e.g. ix where you only can connect to via a carrier (i.e. remote connections).

While I also assume every Network is going to have a physical presence in some building somewhere, from what I can see PeeringDB providers the ability for net records to indicate which (if any) "Private Peering Facilities" they are present in from the list of Facilities with fac objects..

I, and I assume many others, have taken this to mean "Facilities where this network is able to accomodate private peering" rather than "Facilities where this network engages in peering, which are themselves private"... and of course for private peering to be via a dedicated physical interconnect :)

If this is the correct inpterpreration then I would not expect a network which doesnt support 'private peering' to list any facilities in the "Private Peering Facilities" section, even if they are present in one or more Facilities with fac records for the purposes of connecting to a "Public Peering Exchange Point".

Thus to expect Networks to populate the a_side such that the "net_netfac_id is the fac_id of a facility where net is" and "a netfacrecord also should exist" would appear to require networks to indidate they are able to support Private Peering at any Facility they wish to list as the a_side of an netixlan..

Is this intentional?

[arnoldnipper]

If the Network declines to set any value for the a_side (or sets this to the poposed value of "None"), but the IX is encouraged to list the z_side based on where they deliver the service, does this not risk "outing" the network as being present in or near to the z_side facility when they have decided not to share this information?

This only says that the network is connected to the ix in the given facility. However, it does not say anything about where the network is.

[as44980]

This only says that the network is connected to the ix in the given facility. However, it does not say anything about where the network is.

That sounds a lot like "we only know where you phone is located at all times, this does not say anything about where _you_ are located" ;)

[arnoldnipper]

That sounds a lot like "we only know where you phone is located at all times, this does not say anything about where _you_ are located" ;)

You should see more movies on how to trick LEAs etc ;-)

[as44980]

Jokes aside, should Networks have a say on wether an IX publishes information on where the z_side of their connection is located?

FWIW some IX's make this information publically available, some to other members only and at least one which does not disclose this at all ;)

[arnoldnipper]

Jokes aside, should Networks have a say on wether an IX publishes information on where the z_side of their connection is located?

No

[as44980]

Jokes aside, should Networks have a say on wether an IX publishes information on where the z_side of their connection is located?

No

Ergo my concerns that, while this concept has plenty of merits, the proposed implimentation (at best) dilutes the "user submitted" data model by allowing somebody other than the Network to publish data which they may regards as sensitive without their consent :(

[arnoldnipper]

You still have to explain why the network should be authoritative for the z_side. Until then your claim is void.

[as44980]

You still have to explain why the network should be authoritative for the z_side. Until then your claim is void.

I dont beleive that I have suggested the Network should be authoratitive as to the value of the z_side, simply that allowing anyone other than the Network to decide if this value is published would appear to dilute the user submitted data model..

Ie the Network opts to configure and display the a_size values that would clearly be user submitted data, in line with the PeeringDB model.

However i fail to see how having this value set by somebody other than the Network, and as you highlight in this case the user with have "No" say on whether an IX publishes information on where the z_side of their connection is located..

Which to be does not align with the (supposedly) user submitted data model of PeeringDB since the user does not submit the z_side information..

And from what I can gather this model would not consider the z_side data related to where this Network connects to a given IX to belong to the user, even in cases where the IX is contractually prohibited from revealing such details (at least for specific customers).

So IMHO this is slowly, but surely, chipping away at the core concept of PeeringDB's data ownership model...

thus -1 from me :(

[job]

When the IX is contractually prohibited from publishing z_side information, the IX (also a PeeringDB user) should not publish the z_side.

[as44980]

When the IX is contractually prohibited from publishing z_side information, the IX (also a PeeringDB user) should not publish the z_side.

While I dont disagree with this in pricinple, I am concerened that highlighting that an IX is "also a PeeringDB user" is suggesting that information provided by an IX about their members is "user submitted".. is that what is being suggested here?

If so would it also be considered "user submitted" if a facility owner was to request the ability to list all of the networks who it feels to be present in facilities which themselves are owned by the facility operator (contractual oblibations nowithstanding)?

[as44980]

Of course, each net or ix is in some building, but not necessarily in PDB fac. There might e.g. ix where you only can connect to via a carrier (i.e. remote connections).

While I also assume every Network is going to have a physical presence in some building somewhere, from what I can see PeeringDB providers the ability for net records to indicate which (if any) "Private Peering Facilities" they are present in from the list of Facilities with fac objects..

I, and I assume many others, have taken this to mean "Facilities where this network is able to accomodate private peering" rather than "Facilities where this network engages in peering, which are themselves private"... and of course for private peering to be via a dedicated physical interconnect :)

If this is the correct inpterpreration then I would not expect a network which doesnt support 'private peering' to list any facilities in the "Private Peering Facilities" section, even if they are present in one or more Facilities with fac records for the purposes of connecting to a "Public Peering Exchange Point".

Thus to expect Networks to populate the a_side such that the "net_netfac_id is the fac_id of a facility where net is" and "a netfacrecord also should exist" would appear to require networks to indidate they are able to support Private Peering at any Facility they wish to list as the a_side of an netixlan..

Is this intentional?

Would be nice to get feedback on these points as well ;)