peer_type enum

[grizz]

_Originally posted by @compuzip in https://github.com/grizz/autopeer/pull/2#discussion_r1071600472_

s/hard/endless fun/ :D

All good points, creating an issue to discuss, although maybe it's better in the shared doc?

I like the component idea, it seems like we could re-use this in other functions later, we just need to decide what to call it. If we are set on the uri/locator type of format for individual sessions, that's another layer of abstraction that we may want to map to multiple "beginnings of URIs" for session information.

This should just be an enum, I don't see a benefit to having it be a URI. The canonical source of truth for the enum is defined in this spec.

I went back and forth between ix/pni vs public/private. I don't have a strong opinion. I wasn't sure if saying ix was confusing enough in cases where a pni might actually get setup at an ixp? I'm actually also not sure if public/private could lead to confusion on peering with a route server vs directly with another peer. On that note, are we trying to solve for the RS situation with this spec?

I think a PNI by definition isn't over an ixp, even if it's a private vlan. I think we're good no matter what we decide on as long as the docs for each explain clearly the difference.

RS would just be another AS I think? Do we want a boolean for if it's a route server? On the config side I guess it would need to have next-hop-self set.

[jramseyer]

(Moving my comment here from the pull request)

Enum makes sense to me. I like public/private, for the same reason (we might set up pni at an ix, RS).

I would say RS and PNI-at-IX cases both fall into the peer-to-"entity" case, as opposed to the peer-to-peer case (public BGP sessions, etc). By "entity", I mean internet exchange and the like; any entity that doesn't have its own ASN. I would consider the APIs under this spec as "peer-to-peer" API, so we could leave out those other cases.

Let's leave RS out for now, at least. Maybe that could be a third field in the enum (route-server), just in case we support in future?

[compuzip]

I now realize that I wasn't 100% clear in my message and your responses are making me think of a few other things :)

RE: Route Servers, I created #4 so we can track that somewhere separate to this. I think this might actually be more of a "session metadata" type question?

RE: My mentioning the URI and naming the peer type - I think I was more pointing out that if we want to name the enum I made, on the server side there will probably be a deterministic mapping between a session config that has a URI, and the "peer_type" that we had defined. That makes me wonder if "peer_type" isn't right, because eventually we wind up in a scenario where we have something like pdb:ix:$ID would be public, but other_db:whatever:$ID is also public, and those might be different peer types? I wonder if something like "LocationType" (open to other names) is a more accurate depiction of what we're trying to portray with public/private. i.e. #5

[grizz]

Oh right, I had confused myself with the peer_type naming but wasn't fast enough to respond before it got merged. After re-reading I agree completely and think it makes things a lot more clear.

I am still struggling with how ambiguous public and private are (what does that even mean, still), in the case of PDB the choices are ix and facility which I think also makes sense in general.

That doesn't cover doing a private vlan over an IX port yet. but I think leaves room for that as a separate choice for v2.

[compuzip]

I see where you're coming from. On my side of the house we generally use public/private to refer to our peering, but I admittedly don't know how universal this is outside of the CDN industry? Wikipedia seems to classify peering links that way, though: https://en.wikipedia.org/wiki/Peering#Physical_interconnections_for_peering

IX seems pretty ubiquitous (except for old people and certain companies I can think of that have hardcoded NAP everywhere), but I've really only ever seen "facility" used in a peeringdb context and in my mind, even though I know it means colo in pdb-land, it feels ambiguous. I guess my vote would be public/private or ix/pni (if this is a democracy, here 😂)

[grizz]

I'm trying to zoom in on location too much, to start with it's going to be public and an IX as the location, so let's leave it as public and private and wait and see how PNI shakes out.

Definitely not a democracy if we want it to actually make sense. ;) Just in case it is tho, +1 to public/private.