Carrier, colo, and tenant circuit IDs disagree

Examples are fictional local conventions. Unless another location is shown, the scope is DC01 / H1. Keep that scope with shortened identifiers.

When to use

Use this crosswalk when a carrier ticket, colocation order, and tenant inventory use different names for a service handoff. Different identifiers can describe related records without being errors. The useful result is a documented relationship between them.

What to gather

Gather the current provider service reference, cross-connect order, A/Z endpoint details, applicable letter of authorization, tenant connection record, and responsible contacts. Preserve each document's revision or issue date.

Equinix requires its cross-connects to use approved demarcation points. Its LOA ordering workflow carries provider information. These are provider-specific examples. Demarcations; LOA workflow

Identification workflow

These steps are this library's recommended recordkeeping method.

Keep source identifiers intact. Copy provider circuit, cross-connect, and tenant references into separate fields. Preserve punctuation and leading zeros; do not invent a shared ID that overwrites them.
State the handoff endpoints. Record A and Z exactly as defined by the source order, including site, cabinet or panel, and port. Do not assume every organization uses the same direction.
Link the authorization reference. Associate the applicable LOA or accepted service document with the endpoint record. Note a superseded or inconsistent reference for the service owner.
Document the onward connection. Record the tenant's patch from its demarcation to the internal endpoint as a separate relationship. Name its owner so provider delivery and tenant patching remain distinguishable.
Resolve discrepancies across records. Compare endpoint details with the responsible organizations' accepted records. Log the reviewed outcome without ordering, canceling, or authorizing a connection.

The expanded procedures and fictional case below are original editorial recordkeeping guidance to adapt to the site's approved process.

Decide whether the names differ or the endpoints disagree

Different carrier, colocation, and tenant references are not automatically a labeling defect. Start by asking whether the records describe the same accepted service relationship under different names or whether they name different physical endpoints, orders, or service periods. If the identifiers differ but their scoped relationship is supported, build a crosswalk. If the endpoint claims disagree, open a discrepancy. If the current authorization reference is missing or superseded, retain that state separately. Renaming everything to one tenant alias would conceal rather than resolve those distinctions.

Record the service scope before comparing strings. Include the actual provider or party owning each reference, the site and room context, and the order or service event to which it belongs. A short circuit nickname can recur across customers, provider systems, or historical installations. Preserve exact punctuation and leading zeros in the source ID fields. Do not assume two similar references are equivalent or two different references are unrelated; establish the relationship through the applicable accepted records and responsible service owners.

Identify the boundary of your task. This worksheet can reconcile identifiers, demarcations, authorization references, and tenant onward patch records. It does not order, amend, cancel, or approve a service. If a discrepancy needs an amended authorization or provider action, record the required next step and owner while completing the independent crosswalk fields that are already supported. Keep the unresolved endpoint visibly pending so a useful partial record cannot be mistaken for permission to carry out a connection.

Build the source record packet

Collect the current provider service reference, colocation cross-connect order, exact endpoint details, applicable LOA or other accepted service document, and tenant connection record. Preserve each source's identifier, issue information, and status. Record which party owns the source so questions can reach the correct contact or role through the actual service process. A copied spreadsheet is useful as a working index, but the reviewer should be able to retrieve the underlying accepted record rather than relying on an unexplained pasted value.

Keep the carrier circuit, cross-connect ID, and tenant alias in separate columns. Each reference may follow a different lifecycle or describe a different layer of the overall handoff. The crosswalk should explain how they are related for the reviewed scope without asserting that their strings must match. Where a provider issues a replacement order or a tenant changes an internal nickname, retain the historical relationship and its effective event. Avoid overwriting the former reference in a way that makes older tickets impossible to interpret.

Extract the A and Z endpoints using the orientation defined by the source order. Include the site, room where provided, cabinet or panel, and exact port context needed to identify each handoff. Do not reverse A and Z because the tenant diagram is drawn from another viewpoint. If another party uses local and remote labels, record the explicit translation and its source. Orientation is part of the record meaning, not a matter of whichever side happens to appear on the left of a page.

Separate provider delivery from the tenant's onward connection

Record the demarcation relationship according to the actual service arrangement. Then record the tenant onward patch as a separate pair from its demarcation to the tenant's internal endpoint. Include that patch's identity and owner when available. A provider handoff can have a complete crosswalk while the tenant patch remains unverified, and the reverse can also occur. Keep those review states separate instead of using one broad connected status that hides which physical or administrative boundary has been established.

When the LOA or accepted authorization document names an endpoint, compare that detail with the order and current provider record. Preserve an older version as history and identify any disagreement precisely. Matching service aliases do not resolve a port discrepancy. The responsible parties must establish the applicable endpoint through their actual process. The worksheet can record the current reference and accepted outcome afterward, but a local edit to its endpoint cells does not amend the authorization document it cites.

Check any proposed physical face against the ownership boundary and identification policy. A demarcation label might carry the colocation connection ID and exact panel/port context, while the tenant patch retains a separate cable ID and internal endpoint. Preserve the source references needed for the service team to navigate between records. The exact text and placement depend on the actual arrangement; this library's fictional examples do not prescribe a universal provider labeling format or substitute for a service-specific acceptance process.

Worked case: a revised port is not yet reflected in the LOA

In this fictional DC01 / H1 case, provider circuit CAR-G20-301, cross-connect XC-G20-301, and tenant alias WAN-G20-301 are linked in crosswalk XW-G20-301. The observed demarcation face names PNL-G20-301 / P06, and the current provider record also names P06. However, LOA-G20-301 revision 1 names P04. The tenant onward plan shows P06 to RTR-G20-301 / WAN1. Survey DEMCASE-G20-301 records the exact claims and marks the authorization-endpoint relationship unresolved instead of accepting P06 by majority agreement.

The service-record owner follows the applicable provider process to obtain the accepted current reference. In the fictional resolution, LOA-G20-301 revision 2 establishes P06 for the reviewed service scope and is linked through DEC-G20-301. The crosswalk retains revision 1 and its former P04 value historically. It records the unchanged source identifiers and the accepted current demarcation separately from the onward tenant patch CBL-G20-301. The worksheet records that accepted relationship; it does not itself submit an order or create an authorization.

Final review compares the current provider reference, order orientation, accepted authorization version, demarcation identity, and tenant record. The onward patch is checked through its own evidence to RTR-G20-301 / WAN1. If that patch has not been verified, the provider crosswalk can be reviewed while the tenant relationship remains pending with its owner. Closeout records the actual review date and supported scope. It does not claim service activation, traffic performance, or completed installation solely because the identifier fields now agree.

Variations that need more than a renamed row

A circuit migration may retain a tenant alias while replacing a provider circuit or cross-connect reference. Keep the old and new associations with their effective events and service-change record. Determine whether a transition period contains two concurrently relevant relationships instead of overwriting one row too early. The actual migration and service actions belong to their responsible processes; the crosswalk should describe what the accepted records say is current, historical, planned, or unresolved without inventing operational status from a naming change.

Some records describe opposite ends from different viewpoints. Preserve the original A/Z orientation in the authoritative order fields and add a clear translation for the tenant's local/remote terms. Check the translation against the complete panel and port references, not just the endpoint letters. A row can look consistent while quietly exchanging A and Z if the author assumes all organizations use the same viewpoint. Retain the source of the translation so a future reviewer can reconstruct the original order meaning.

If a tenant internal endpoint changes while the provider demarcation remains the same, update the onward relationship through its change record and review its cable faces separately. Do not invent a new carrier circuit ID to describe a tenant patch move. Conversely, a changed demarcation may affect the authorization and provider records even if the router and tenant nickname remain unchanged. Identify the boundary affected by the change and involve the owner responsible for that boundary rather than treating all fields as one interchangeable connection name.

Failure patterns and evidence for closure

Watch for leading zeros removed in exports, carrier IDs replaced by nicknames, obsolete authorization versions cited as current, and tenant cable IDs entered into the provider cross-connect field. Each erases a relationship the service team may need during a later ticket. Preserve original source strings and compare exact values before declaring a mismatch. If a record uses an alias intentionally, document that alias in its own field and retain the controlled reference that explains which service relationship it represents.

The final evidence packet should support each organization's reference, both scoped demarcation endpoints, the accepted authorization relationship where applicable, and the separate onward tenant pair. State the owner and unresolved detail for any missing link. A screenshot of a provider portal may establish a displayed order field but not the installed tenant patch. A photograph of the demarcation face may establish visible identity but not the status of the service order. Keep each evidence claim limited to what its source supports.

Worked example

Example only: fictional service identifiers.

SCOPE: DC01 / H1
Carrier CIR-0048 -> Colo XC-0917 -> Tenant WAN-02
A: DC01 / DEM-01 / 07
Z: DC01 / DEM-08 / 12
Tenant onward: DEM-01/07 -> EDGE-01/WAN1

The three service references remain distinct. The onward patch describes a separate tenant relationship.

Common mistakes

Replacing the carrier reference with a tenant nickname.
Reversing A/Z because a local diagram is drawn differently.
Treating an old LOA as the current endpoint record.
Omitting the onward patch after the provider demarcation.

Verification

Each organization's exact identifier is preserved.
A/Z orientation follows the cited order.
Panel and port details identify both handoffs.
Authorization references match the relevant service record.
The onward patch and its owner are documented.

Worksheet: Colocation demarcation and ID crosswalk

Field	Definition
Provider circuit	Exact carrier or service-provider reference.
Cross-connect ID	Colocation provider's connection reference.
Tenant alias	Tenant's internal service reference.
A demarcation	A endpoint as defined by the source order.
Z demarcation	Z endpoint using the same order orientation.
LOA reference	Applicable authorization document identifier/version.
Tenant onward patch	Separate tenant-side endpoint relationship.
Status	Crosswalk review state or specific discrepancy.
Evidence	Provider order and tenant-record references.
Owner	Service-record owner coordinating organizations.
Verification date	Actual date the record relationship is checked.

Filled example row - fictional; no live verification.

Provider circuit	Cross-connect ID	Tenant alias	A demarcation	Z demarcation	LOA reference	Tenant onward patch	Status	Evidence	Owner	Verification date
CIR-0048	XC-0917	WAN-02	DC01 / DEM-01 / 07	DC01 / DEM-08 / 12	Fictional LOA-008 rev 2	DEM-01/07 to EDGE-01/WAN1	Pending endpoint review	Fictional order ORD-0917; EX-20	Example tenant connectivity team	Not verified (fictional)

FAQs

Must the carrier and tenant use the same circuit name?

No. Preserve both references and document their relationship within the same handoff record.

Does the completed worksheet authorize a cross-connect?

No. Authorization and service orders remain with the provider's actual process and the responsible customer.

What if the tenant nickname stays the same during a migration?

Retain it as the tenant alias and record the old and new provider relationships with their effective events and change reference. Mark any transition state explicitly. An unchanged nickname does not mean the same circuit, cross-connect, or demarcation remains current throughout the migration.

Can I swap A and Z to match my local drawing?

Keep A and Z as the cited source order defines them. Add a documented translation to the local drawing's viewpoint when needed, using complete endpoint references. Swapping the values without explanation makes the record harder to reconcile with the provider's order and authorization information.

Is a matched demarcation enough to close the onward patch?

No. The onward patch is a separate tenant relationship with its own endpoints, identity, and evidence. Record the demarcation result and leave the tenant pair pending if it has not been checked. Name its owner so the remaining work can proceed without reopening already supported provider fields.

Should I delete a superseded LOA from the working history?

Retain its reference and status according to the applicable records process, while clearly identifying the accepted current version. Historical endpoint values can explain older tickets or labels. Do not leave a superseded version presented as current, and do not infer an amendment from a local spreadsheet edit.

More worked label examples

Two additional ways to apply this guide. Keep the exact identifiers and relationships consistent with your own approved records.

GUIDE 20 / EXAMPLE 1

Preserve three organizations' circuit references at a handoff

The crosswalk keeps carrier, colo, and tenant identifiers intact while the physical boundary and tenant onward patch remain explicit.

SCOPE: DC01 / H1; fictional provider and tenant arrangement
CARRIER REF: CAR-G20-101
COLO CROSS-CONNECT: XC-G20-101
TENANT ALIAS: WAN-G20-101
All three -> service crosswalk XW-G20-101

PROVIDER SIDE            DEMARCATION             TENANT SIDE
PNL-G20-101 / P01 ===== PNL-G20-102 / P12 === RTR-G20-101/P1
    provider patch          boundary           onward patch

DEMARC LABEL FACE
[XC-G20-101 | PNL-G20-102/P12 | DC01-H1 / R102]
TENANT PATCH FACE: [CBL-G20-101 | TO RTR-G20-101/P1]
Authorized endpoint reference: LOA-G20-101 r2
Ownership: provider through demarc; tenant onward in this example

FICTIONAL EXAMPLE / NOT TO SCALE

Replace the boundary and responsibility statement with the actual service agreement and provider process. A demarcation arrangement at one site does not establish ownership at another.
Retain each party's exact reference rather than renaming them into one common ID. Check that the current authorization names the same physical termination before treating the crosswalk as ready.

GUIDE 20 / EXAMPLE 2

Reject a stale authorization endpoint without losing aliases

The service names match, but the port on the older authorization differs from the current provider record, so endpoint confirmation remains open.

SCOPE: DC01 / H1; crosswalk XW-G20-201
SERVICE IDS: CAR-G20-201 / XC-G20-201 / WAN-G20-201

OBSERVED DEMARC FACE: [XC-G20-201 | PNL-G20-201 / P06]
OLDER LOA-G20-201 r1:  PNL-G20-201 / P04
PROVIDER RECORD r3:    PNL-G20-201 / P06
TENANT PATCH PLAN:     PNL-G20-201 / P06 -> RTR-G20-201/P2

DISCREPANCY: authorization endpoint P04 versus P06
STATUS: HOLD; request current authorized endpoint reference

RESOLUTION EXAMPLE AFTER PROVIDER CONFIRMATION
LOA-G20-201 r2 -> P06; retained history -> former P04
Final crosswalk -> XC-G20-201 / PNL-G20-201/P06