Does Interconnect on letter I share fate with other letters?

The control plane is shared. Data-plane queues for Interconnect stay isolated, so incident i-01 cannot drain neighbor letters.

Where is Interconnect measured first?

From Santiago (SCL) toward Bogotá. A global average is not an SLO for letter I.

How fast is rollback for i-03?

The runbook is a command plus a named owner. There is no wait for a weekly change freeze.

Is transit the default path?

No. Peering in Miami is default; transit to São Paulo is overflow and is billed that way.

Interconnects where Latin American IXPs already meet

Private interconnects and public IX fabrics cut transit bills and keep packets off detours through distant hubs.

Interconnect: Why it matters on this continent

Design for Interconnect on letter I starts in São Paulo (GRU). Runbook i-01 keeps a single owner, a written rollback, and a traffic split that can be reversed without a global freeze. Neighbors in Santiago only take overflow after the local pool fails a health window.

Interconnect: How XServ runs it day to day

Probes for Interconnect (i-02) leave Santiago every 15s toward Bogotá. XServ pages the named owner if loss or RTT crosses the letter budget. A probe never shares a queue with bulk transfers, so a saturated WAN does not hide a dead PoP.

Interconnect: What operators should measure

Policy for Interconnect is versioned as i-03. Operators measure error rate, p95 from Bogotá, and time-to-rollback — not a worldwide average. Changes land in Bogotá first, then Miami, with a hold if either region regresses.

Interconnect: Failure modes we actually see

Capacity notes for i-04 assume rainy-season power in Miami and festival peaks toward São Paulo. The failure we actually see is a single uplink, not a cartoon partition of the whole continent. Spare ports and a second provider sit on the same runbook.

Interconnect: How this letter ties to the rest

Handoff from letter I Interconnect into the rest of the platform uses the same request IDs as the gateway. Runbook i-05 names who accepts the ticket after São Paulo pages out. Santiago does not silently inherit the incident.

Interconnect: A note on cost and transit

Rollback for i-06 is a documented command, not a hope. Transit is billed as backup while Interconnect prefers peering in Santiago. If cost spikes, the runbook cuts overflow to Bogotá before touching customer prefixes.

Interconnect design I-01

Interconnect probe I-02

Interconnect policy I-03

Interconnect capacity I-04

Interconnect handoff I-05

Interconnect rollback I-06

Interconnect peering I-07

Peering for Interconnect (i-07) prefers the IX fabric that already carries last-mile ISPs in Bogotá. Session counts and prefix limits are on the same page as the Miami backup path.

Interconnect cache I-08

Cache rules for Interconnect on i-08 keep language-correct objects near Miami. São Paulo is a sibling cache, not an origin. TTLs are short enough that a bad asset does not live through a weekend.

Interconnect headers I-09

Headers for i-09 carry the letter, the region (GRU) and a request id. Interconnect debugging in São Paulo should not require a packet capture in Santiago first.

Interconnect timeouts I-10

Timeouts on i-10 are tighter than the WAN RTT to Bogotá. Interconnect in Santiago fails fast and retries once; a third try needs a human because it is no longer a blip.

Interconnect regions I-11

Region names on i-11 match DNS and tickets: Bogotá / BOG, with Miami as the documented pair. Interconnect dashboards never say “LATAM” as if it were one RTT.

Interconnect docs I-12

Public docs for letter I stay aligned with identifier xserv-i-pack. Page i-12 is the Interconnect slice operators search before the homepage. Edits in Miami show up in São Paulo on the next publish.