Release Notes 6.4
Portal URL: https://ecxfabric.equinix.com/
Equinix Cloud Exchange Fabric's ECX 6.4 August 19th, 2019 release delivers a set of new features over its predecessor release ECX 6.3. Details on the new features are listed in the Release Summary section below.
This release broadly increases the breadth of Cloud Exchange Fabric's capabilities through the following features:
- Re-instatement of Port Utilization feature.
- Bandwidth resizing for private Layer 2 connections and/or non-integrated CSPs (includes remote connections)
- Migration from Classic APIs to Azure Resource Manager (ARM) APIs. This change was mandated by Microsoft because classic APIs will be deprecated by December 2019.
- Display physical port information in ECXF and present a "List View" for ports
- Capability to provide custom VC names for customers whose naming requirements require a custom name
A feature that facilitates discovering other Equinix customers helps to find each other and increases the usefulness and density of the ECX platform. To achieve this, we need as much information as possible to allow for users to properly identify who they want and need to get to.
Visibility and exposure settings allow Equinix accounts to self-identify (or derive some info from internal systems) about themselves so they can be found, regardless of other automatic assumptions or rules that may be applied to them. Where possible, the company profile is derived from other systems and web properties that Equinix already has live (such as the Marketplace or SFDC), and only additional info desired will augment the record.
- The ECX Fabric Portal, Network Edge and Resource Center have been translated into Japanese. Equinix Japan works mostly with native Japanese companies.
Here are the high-level feature descriptions delivered in this release.
Reinstate Port Utilization in the Portal
Port Utilization has been reinstated within the portal. Portal users can now view traffic statistics for cloud exchange ports.
- Traffic is measured in Megabits per second (Mbps) and represents the amount of bandwidth being consumed between two points at a given time. Customers can view and analyze the utilization of inbound and outbound traffic of any port, across all services and profiles active on that port. This new display is available via the components tab from the main screen. then selecting Ports. Expand the arrow representing the desired port to see the traffic. Traffic statistics are then automatically displayed in a graph.
Traffic statistics are collected in five minute intervals and can be filtered by previous day, week, month or year simply by clicking the gray box in the upper right corner of the display. Each time period (previous day, week, etc.) is taken from 12 a.m. (midnight GMT) of the initiation of the time period to 12 a.m. (midnight GMT) of the finalization of the time period.
For example, if the customer wants to view utilization data for the previous month, data will be captured from midnight on the 1st day of the month through midnight on the last day of the month.
Note: Graphs will be retroactive to the point when data collection began. In some cases, this date could vary but will become consistent over time.
- The graph also shows the maximum (measured) and average utilization, in Mbps, for both inbound and outbound traffic as well as the last value measure for the designated time period. Hovering over any particular point of the graph will show the applicable spot value at that point in time.
List View Phase II - Enhanced Connections Information
List View Phase II extends support delivered in the previous phase. For this release, we’ve added export capabilities for Connections List View. This is also the ability to export all list view data to a .csv file so customers can manipulate the data to meet their individual business needs.
The following additional Connections list view fields are added:
- Bandwidth tier/speed
- VLAN id (s)
- Virtual circuit name
- NEW FIELD - END-USER NAME (for resellers who create connections on behalf of their customers. It will store the actual customer name for whom the connection was created.).
- Data Center origin and destination (IBX preferable) vs Metro if possible.
- Order number
This view defaults to show active connections only.
In addition, this update includes further condensing some of the longer fields so more can fit on the page (ex. “Customerconnectionname” becomes “Customer…name”). We’ve added tooltips to explain several of the columns that are not intuitive. Also included is the ability to Display and sort against the name of the company ordering inbound VCs for sellersA seller is a user who makes their services available to end customers through ECX. This guide refers to sellers for shorthand, but ECX generally regards a “seller” as an activity rather than a static person..
Full Bandwidth Resizing Capabilities Phase II
This release also includes bandwidth resizing for private Layer 2 connections. This includes remote connections.
Use Case: A customer has a Layer 2 connection between two ports on the ECX FabricECX Fabric is an advanced interconnection solution that improves performance by providing a direct, private network connection that they own. Those connections are not to another CSP. The customer initially ordered 50M but now want to increase to 1G. In this case, no approvals of the bandwidth upgrade would be required but they would need to acknowledge a billing increase.
Policy implemented with this release: only one bandwidth change is permitted during a 24-hour period.
For example, if you dial the bandwidth up at 3 p.m. on Tuesday, you cannot make another change to the bandwidth again until 3 p.m. on Wednesday.
Microsoft ExpressRoute API Migration from Classic to ARM
Microsoft has asked their ExpressRoute partners to migrate from Classic APIs to Azure Resource Manager (ARM) APIs. This API set provides greater functionality and allows for ease of updating bandwidth changes (increases) and link state in ECXF. We have made this change accordingly.
Benefits of this migration:
- Better support from Microsoft
- Provisioning API call time will decrease - resource management ("Shadow") is better on the MSFT side
- The new API uses a push model instead of just a pull mechanism
In addition, redesigning the "read" configs so that if any other CSP changes their API, we can implement those changes more quickly.
Display Port Information
Today, ECXF users who want to obtain physical port information must refer to ECP for this information. This is the only shared field between ECXF and ECP, it allows for customers to correlate their ports or port LAG groups is the cable ID for the primary physical port.
Our customers are asking for a more intuitive display of their physical port details that eliminates the need to move between both portals.
This feature has two high level objectives:
- Display physical port information in ECXF
- Present a list view for ports
This feature fulfills the following requirements: basic list view for ports with filtering criteria and customers have access to see the Cable ID (aka CCID or Serial) in the details for each of their ports.
Customers also gain the following functionality:
- The ability to view ports in an SVC
- The ability to select a port or port lag group, and view all connections on the port(s)
- Sort/filter functionality that’s similar to connections list view
- Port name/ID can be selected. A modal should pop up showing additional info about the port (same as connections list view).
- Information displayed regarding ports includes: port name, metro, speed, port type (QinQ/etc), lag yes/no, total bandwidth of all connects on port, last updated timestamp.
- In addition, the new portal no longer shows if ports have unlimited packages
- Display order
- Display port utilization
- Display order information such as cabinet, cage and patch panel
Custom VC Names
With this release, customers can specify a custom VC name based on their own naming nomenclature requirements.
This feature has a few limitations and dependencies
- UI/API limitation: The port and VC name cannot exceed 24 characters.
- Hyphen, special characters, letter, number, underscore are allowed but the name cannot end with a hyphen.
- Any ECXF user with org level permissions can edit the VC names associated with the org
- Out of scope: Custom Port Names
Discovery- Account, Profile Exposure and Visibility settings
Discovery helps customers find each other and increases the usefulness and density of the ECX platform.
To enable customers to find each other, we need to have as much information as possible so users can properly identify who they want and need to get to connect.
Visibility and exposure settings allow Equinix accounts to self-identify (or derive some information from internal systems) about themselves so they can be found, regardless of other automatic assumptions or rules that may be applied to them.
Where possible, the company profile is derived from other systems and web properties that Equinix already has live (e.g. Marketplace or SFDC) and only additional info desired will augment the record.
At present, customers can either have a public profile and be findable or they can be hidden. Future enhancements may offer additional levels of visibility.
Basic company profiles will include the following items (with specific user story/workflow below):
- A basic set of information about the COMPANY based on GCID, not just the services offered on ECX
- A statement on how visible they want to be to others, or the rules they want set for how other accounts can see and interact with them:
- The company is fully discoverable and can be contacted whether an ECX service is defined or not
- The company can only be reached through connection requests to any existing and visible profile.
- The company can only be reached via email to request some access; profiles are not visible unless that visibility granted by the customer.
- The company is not visible under any circumstances to other ECX users
Note: There is an additional future master feature that would allow this type to generate a proactive permission to another account to connect to them, but is not assumed in this scope.
- A way to point the company profile to existing data sets, e.g. in the marketplace
- Editing capabilities to add useful information to the company profile if desired
- A way to associate all public and private profiles to that company profile so they can be chosen from when deciding how to interconnect
- A way to mark individual service profiles as more restrictive than overall account settings; for example, company can be reached by any visible profile, but marks a specific profile as only for internal use or by invite only
Customers, many of whom do not interface directly or regularly with marketplace, will have an additional and user-friendly/familiar place to adjust their profile to maximize search results. This ties two key web properties and their functionality together to create a more seamless user experience and make it easier to access.
The information customers provide via this feature will help Equinix build a deeper and larger ecosystem.
What does a customer do without this feature?
Without discovery, customers typically have no alternative other than ad hoc and "chance" encounters outside of the ECX. They can conduct independent research to determine who may be connectable but this is time consuming and inaccurate. Customers can also use other Equinix tools like marketplace or matchmaker, but these often cater to use cases or transactions not related to the ECX core principles, and it is not always obvious that ECX is a viable alternative even when they do find some results.
ECX Fabric SLA reporting
This feature delivers a way to measure and report performance, primarily focused on the inter-metro ECX Fabric remote connections performance.
Included with this feature:
- Focus on intercity latency
- 3-month history
In addition, this feature adds the ability to report monthly performance against our stated SLAs.
This feature allows a Master administrator for an organization to control from where and when domain users can access the portal. This feature adds the ability to restrict organization login to specified source IP addresses.
When customers are unable to restrict when and from where their users can log in, they have much less control over preventing account misuse. Customers are reluctantly forced to allow access to the portal from any location, which is perceived by some customers to be a major security concern.