Clarification of campus definition

[as44980]

While the original thread that create the campus object (https://github.com/peeringdb/peeringdb/issues/1110) states:

In today's @peeringdb/pc meeting there was an agreement that a campus could be defined by inter-building x-connects being available on the same basis as intra-building x-connects.

The meeting notes (https://docs.peeringdb.com/committee/product/notes/2022-09-08_Product_Committee_Notes.pdf) state:

Consensus on a campus being defined by an inter-building x-connect being available with the same ease as an intra-building x-connect

And the getting started guide for Facility and Campus operators (https://docs.peeringdb.com/howto/get-started-facility/) states:

A campus is two or more facilities owned by the same organization where customers can get inter-facility cross-connects.

Please can we have a single, consistent definition that makes it clear if there any specific requirements or expectations of inter-building cross connects..

Do these need to be available on the "same basis" and/or with the "same ease" as intra-building cross connects?

And are there any distance limitations between sites which can be considered to be part of the same campus? :)

[arnoldnipper]

And are there any distance limitations between sites which can be considered to be part of the same campus? :)

Iirc, there was a lengthy discussion on that. Consensus was what you can reach with 10G-LR w/o amplifiers.

[martinhannigan]

On Wed, Apr 10, 2024 at 13:02 as44980 @.***> wrote:

While the original thread that create the campus object (#1110 https://github.com/peeringdb/peeringdb/issues/1110) states:

In today's @peeringdb/pc meeting there was an agreement that a campus could be defined by inter-building x-connects being available on the same basis as intra-building x-connects.

The meeting notes ( https://docs.peeringdb.com/committee/product/notes/2022-09-08_Product_Committee_Notes.pdf) state:

Consensus on a campus being defined by an inter-building x-connect being available with the same ease as an intra-building x-connect

And the getting started guide for Facilty and Campus operators ( https://docs.peeringdb.com/howto/get-started-facility/) states:

A campus is two or more facilities owned by the same organization where customers can get inter-facility cross-connects.

Please can we have a single, consistent definition that makes it clear if there any specific requirements or expectations of inter-facilty cross connects..

Do these need to be available on the "same basis" and/or "same ease"?

it sounds like you are talking about cost. If not, my apologies. If so, this is out of scope for Peeringdb.

[as44980]

And are there any distance limitations between sites which can be considered to be part of the same campus? :)

Iirc, there was a lengthy discussion on that. Consensus was what you can reach with 10G-LR w/o amplifiers.

There was some discussion prior to the reported "consensus", but this doesn't appear to have made it into any published definition of a PeeringDB campus... does this apply, and if so should this be clearly and consistently stated? :)

it sounds like you are talking about cost. If not, my apologies. If so, this is out of scope for Peeringdb.

I am merely quoting what appear to be 3 inconsistent definitions of a "PeeringDB Campus" and asking which of these should be considered authoritative..

While if this was to be either of "same basis" or "same ease" then I would be keen to have clarification on what criteria PeeringDB would use to validate that any campus objects are aligned to the chosen definition :)

[martinhannigan]

On Thu, Apr 11, 2024 at 4:04 PM as44980 @.***> wrote:

[ clip ]

it sounds like you are talking about cost. If not, my apologies. If so, this is out of scope for Peeringdb.

I am merely quoting what appear to be 3 inconsistent definitions of a "PeeringDB Campus" and asking which of these should be considered authoritative..

While if this was to be either of "same basis" or "same ease" then I would be keen to have clarification on what criteria PeeringDB would use to validate that any campus objects are aligned to the chosen definition :)

I have less trouble with campus object than carrier object. But let's not get distracted. :)

Here's an example of good use of campus object: https://www.peeringdb.com/campus/11

The UI is a problem here for me https://github.com/peeringdb/peeringdb/issues/1591. Besides that, when you implement it correctly, it seems to make sense including what networks you should be able to use to move between them. Its not clear if you can get dark fiber from the facilities owners in the campus object, but I would "assume" you can get a cross connect and expectation would be its inhouse and not extended from a basis view.

An MMR object would clarify your concern IMHO. Something we are working on. Or did I miss the point entirely?

Thanks!

Message ID: @.***>

[martinhannigan]

I wouldn't take those words to heart. They are not a representation of what was actually said, but an interpretation.

PeeringDB can not define what a cost basis is or ease. And I can see your point on clarity.

• A campus is two or more facilities owned by the same organization where customers can get inter-facility cross-connects.

That really should be it. And leaving cost and ease between the ordering parties and the vendor.

HTH,

-M<

On Wed, Apr 10, 2024 at 1:02 PM as44980 @.***> wrote:

While the original thread that create the campus object (#1110 https://github.com/peeringdb/peeringdb/issues/1110) states:

In today's @peeringdb/pc meeting there was an agreement that a campus could be defined by inter-building x-connects being available on the same basis as intra-building x-connects.

The meeting notes ( https://docs.peeringdb.com/committee/product/notes/2022-09-08_Product_Committee_Notes.pdf) state:

Consensus on a campus being defined by an inter-building x-connect being available with the same ease as an intra-building x-connect

And the getting started guide for Facilty and Campus operators ( https://docs.peeringdb.com/howto/get-started-facility/) states:

A campus is two or more facilities owned by the same organization where customers can get inter-facility cross-connects.

Please can we have a single, consistent definition that makes it clear if there any specific requirements or expectations of inter-facilty cross connects..

Do these need to be available on the "same basis" and/or "same ease"?

And are there any distance limitiations between sites which can be considered to be part of the same campus? :)

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1590, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQXA46YU4YPOLHRDD6TY4VWCDAVCNFSM6AAAAABGA2GJ52VHI2DSMVQWIX3LMV43ASLTON2WKOZSGIZTMMBVGY2DQMQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[juanitoe]

Hi,

Via Caldera for instance in Milan is a campus - in my mind, without a single owner, and caveats for inter building connectivity. Yet, it's a single address. What do we call those then ? Interconnection price is a matter for the local loop providers - maybe there should be a field for multi tenants campuses with the operators of local DF/Waves between buildings/rooms?

Regards, -Jean

On Thu, Apr 11, 2024 at 10:57 PM Martin Hannigan @.***> wrote:

I wouldn't take those words to heart. They are not a representation of what was actually said, but an interpretation.

PeeringDB can not define what a cost basis is or ease. And I can see your point on clarity.

• A campus is two or more facilities owned by the same organization where customers can get inter-facility cross-connects.

That really should be it. And leaving cost and ease between the ordering parties and the vendor.

HTH,

-M<

On Wed, Apr 10, 2024 at 1:02 PM as44980 @.***> wrote:

While the original thread that create the campus object (#1110 https://github.com/peeringdb/peeringdb/issues/1110) states:

In today's @peeringdb/pc meeting there was an agreement that a campus could be defined by inter-building x-connects being available on the same basis as intra-building x-connects.

The meeting notes (

https://docs.peeringdb.com/committee/product/notes/2022-09-08_Product_Committee_Notes.pdf)

state:

Consensus on a campus being defined by an inter-building x-connect being available with the same ease as an intra-building x-connect

And the getting started guide for Facilty and Campus operators ( https://docs.peeringdb.com/howto/get-started-facility/) states:

A campus is two or more facilities owned by the same organization where customers can get inter-facility cross-connects.

Please can we have a single, consistent definition that makes it clear if there any specific requirements or expectations of inter-facilty cross connects..

Do these need to be available on the "same basis" and/or "same ease"?

And are there any distance limitiations between sites which can be considered to be part of the same campus? :)

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1590, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AFA2YQXA46YU4YPOLHRDD6TY4VWCDAVCNFSM6AAAAABGA2GJ52VHI2DSMVQWIX3LMV43ASLTON2WKOZSGIZTMMBVGY2DQMQ>

. You are receiving this because you are subscribed to this thread.Message ID: @.***>

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

[martinhannigan]

I don't see how we could define a campus which includes different buildings with different owners and FAC'kers, (cabinets who purport to be a data-center but really are a tenant in a FAC). Letting a single entity define their campus object seems reasonable.

[as44980]

On Thu, Apr 11, 2024 at 4:04 PM as44980 @.***> wrote: [ clip ] Its not clear if you can get dark fiber from the facilities owners in the campus object, but I would "assume" you can get a cross connect and expectation would be its inhouse and not extended from a basis view. An MMR object would clarify your concern IMHO. Something we are working on. Or did I miss the point entirely? Thanks!

Yeah perhaps talking cross purpose, my understanding from the previous discussion was that the campus object was specifically intended to groups facilities where the owner provided some sort of interconnection between those facilities.. ;)

I wouldn't take those words to heart. They are not a representation of what was actually said, but an interpretation.

Sadly without a recording or transcribed minutes, that is all anyone outside the PC has to go on.. hence the request for clarification of the multiple definitions :)

PeeringDB can not define what a cost basis is or ease.

If that is the position, why were "same basis" and "same ease" even mentioned in minutes and "interpretation" fed back to the github thread? ;)

And I can see your point on clarity. - A campus is two or more facilities owned by the same organization where customers can get inter-facility cross-connects. That really should be it. And leaving cost and ease between the ordering parties and the vendor. HTH,

Hopefully we will all benefit from a single, consistent definition... and I agree simpler would be better, but does the previous discussion not suggest that even your proposed definition would still require clarification as to what qualifies as a "cross connect"?

I don't see how we could define a campus which includes different buildings with different owners and FAC'kers, (cabinets who purport to be a data-center but really are a tenant in a FAC). Letting a single entity define their campus object seems reasonable.

I also agree that the intention of the campus object was to group facilities owner (or perhaps more accurately managed) by the same operator :)

[mcmanuss8]

+1 we should clarify what the policy is and make sure it's well documented

[grizz]

+1 we should clarify what the policy is and make sure it's well documented

+1 to that.

[leovegoda]

Updated documentation, so closing