Offering services for sale on the ECX begins with choosing whether to offer as a “Layer 2” or “Layer 3” service model. This will impact the minimum viable workflow and pre-requisites that a user must have when buying the service. Although everyone has preferences, we recommend consultation with Equinix personnel, product, engineers and architects, if you are unsure which path you would rather take.
A Layer 2 service is created by combining ports into a service profile, and then defining its characteristics and business rules.
The following is the basic workflow to get started:
Throughout the lifecycle of your service, you may add ports in new or existing markets (for capacity), you may remove them or you may upgrade and change certain aspects of your service.
Another critical task is to review and approve connection requests as they are made. This can be done manually through the portal, automatically by coding to the API or, with prior arrangement and ECX development, by having ECX integrate into your provisioning systems. In any case, the primary items that must be determined per connection request include:
- Whether the requestor has a valid authentication ID, if relevant and asked for
- To which local port the user’s connection should be terminated, depending on your preference, fill factor, capacity management decisions, and other factors at your discretion
- To which VLAN the connection should be mapped on your port
ECX will not begin provisioning and orchestration of the connection, and will not consume any of the physical or logical resources, until approval has occurred. Once approval has been
received, however, the entire workflow to completion will occur within seconds and the user will be capable of sending traffic to your service within minutes.
Some providers require their users to perform certain actions in their own portal or tools, such as selecting the interconnection provider (in this case, Equinix is the provider). If this is necessary, it is important that the provider make clear to their customers the order of events in their own documentation. You may also wish to clarify when an end customer will be going through an intermediary to get to Equinix, and is unaware that their intermediary will be using the services of Equinix s for this task.
Often, it involves coming to your portal and services first, setting up or buying something, taking specific information from that transaction to the ECX, provisioning a connection, and sometimes even coming BACK to your portal to finalize details. This frequently confuses users; Equinix cannot customize guidance for every provider with a discrete, private interconnection offer.
When a buyer chooses Equinix as the connectivity option, the provider should link the buyer to the CXP automatically or point to the CXP link (http://cloudExchangeportal.equinix.com) to order connections.
In most scenarios, buyers and providers will use Dot1q type ports. Some providers choose to use Q-in-Q ports, especially if they offer more than one subscription service to their users. This allows their systems to identify an S-Tag as a single customer incoming on an aggregated port, and then the C-Tags below will indicate the service for which it is bound. While this can be very helpful for providers and buyers alike, it can also be highly confusing for buyers.
Because ECX systems have no way of knowing which C-Tag will be bound for which service, a buyer is normally required to gather this information from the provider in advance, and enter it into the ECX when creating a connection. For this purpose, ECX offers the optional service called “Enhanced Dot1q to QinQ Translation Support.” This service allows a provider to name the services that a buyer will connect with; when the buyer creates a connection, the system will present them with these more familiar names in lieu of the C-Tag matching exercise. For example, a provider might define “Acme Cloud Storage” and “Acme Cloud Compute” and “Acme Cloud CRM.”