Summary

  • LACNIC’s 13 October account recommends full BGP routes over fibre and only a default route over LEO, so satellite would carry traffic after the fibre path fails.
  • The route rule does not detect a cable fault. LACNIC reports exercises, but names no operator deployment, withdrawal timer, capacity test or recovery result.

A route policy, reported after the event

CaribNOG 32 met in Willemstad, Curaçao, from 7 to 9 October. In a post published on 13 October, LACNIC says Alejandro Acosta and Nicolás Antoniello led a technical session after an introduction by ARIN’s Mark Kosters. The account says Acosta adapted the advice to the Caribbean’s submarine-cable exposure, storms and other hazards. It is LACNIC’s event report, not an independent survey of island networks.

The recommendation is concrete: connect to at least one submarine fibre route, preferably more than one; keep the full routing table on fibre; and accept only a default route over a low-Earth-orbit satellite link. The satellite path is intended to carry traffic when the cable path fails. LACNIC also cautions that one LEO link may not support traffic from many ISPs, but publishes no capacity, load profile or test behind that warning.

The missing step is withdrawal

A default route serves destinations without a more-specific entry. It is not a fault detector. Fibre-learned routes remain preferred for their destinations because they are more specific; traffic shifts to the satellite default only after those routes disappear or policy changes. If a failed path leaves stale routes in place, the fallback can remain unused while packets continue toward a dead end.

That makes the detection and withdrawal rule central. Does a physical interface going down withdraw the route? Does the operator rely on BGP session loss, BFD, or an active service probe? How long may the route persist, and what prevents an unstable fibre link from repeatedly switching traffic? LACNIC describes the desired arrangement but gives no parameters and reports no failover test on a live network.

Security tools have narrower jobs

The account mentions RPKI origin validation, BGP leak controls and BFD. RFC 6811 checks whether the origin AS is authorized for a prefix; it explicitly does not validate the full AS path. RFC 9234’s leak mechanism depends on eBGP neighbors agreeing their roles and marking routes, alongside operator policy. Neither establishes reachability or deployment.

LACNIC says BFD can shorten detection from roughly 90 seconds to milliseconds. RFC 5880 makes detection depend on negotiated intervals and a detection multiplier; the post gives no configured timers. It also notes that IPv6 Path MTU Discovery needs ICMPv6 messages to pass, as RFC 8201 explains. LACNIC reports afternoon exercises in DNSSEC resolver configuration and RPKI origin validation. That is evidence of training, not production adoption.

The public record establishes a design recommendation and exercises. It does not establish how many networks use it, whether LEO capacity is adequate during a cable outage, or how quickly traffic recovers.

Sources: LACNIC’s post-event account; CaribNOG 32 agenda; RFC 6811; RFC 9234; RFC 5880; RFC 8201.