35 lines
1.2 KiB
Org Mode
35 lines
1.2 KiB
Org Mode
#+TITLE: How do Interconnections work for dummiez
|
|
#+Author: Adam Mohammed
|
|
|
|
|
|
* User Flows
|
|
|
|
User starts by making a API call to ~POST
|
|
/projects/:id/connections~. When they make this request they are able
|
|
to either able to use a full dedicated port, on which they get the
|
|
full bandwidth, or they can use a shared port. The dedicated port
|
|
promises you get the full bandwidth, but is more costly.
|
|
|
|
A user is also able to to select whether the connection at metal is
|
|
the A side or the Z side. If it's the A-side, then Metal does the
|
|
billing, if it's the Z-side, Fabric takes care of the billing.
|
|
|
|
A-side/Z-Side is a telecom terminology, where the A-side is the
|
|
requester and the Z side is the destination. So in the case of
|
|
connecting to a CSP, we're concerned with a-side from metal because
|
|
that means we're making use of Fabric as a service provider to give us
|
|
connection to the CSP within the metro.
|
|
|
|
If we were making z-side connnections, we'd be granting someone else
|
|
in the DC access to our networks.
|
|
|
|
|
|
* Under the Hood
|
|
|
|
when the request comes in we create
|
|
|
|
- An interconnection object to represent the request
|
|
- Virtual Ports
|
|
- Virtual circuits associated with each port
|
|
- A service token for each
|