Some new design docs
This commit is contained in:
34
design/interconnection-models.org
Normal file
34
design/interconnection-models.org
Normal file
@@ -0,0 +1,34 @@
|
||||
#+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
|
||||
Reference in New Issue
Block a user