OVH US LLC in the RIPE Ledger: What Must an Exit-Ready BYOIP Plan

Summary

RIPE NCC lists OVH US LLC as a member under the United States. That is a useful administrative identity in a regional number-resource system, but it does not identify a particular OVH US LLC prefix, ASN, route, facility, customer, cloud service or operating result.
OVHcloud publicly describes a Bring Your Own IP service in which a customer brings eligible public IPv4 space, remains responsible for the addresses and their reputation, and uses an OVHcloud or customer AS to announce the range. Those branded documents describe a control surface; they do not prove which legal entity contracts or operates every regional deployment.
Four records need to be kept separate: the regional registry records who has authority over number resources; a Route Origin Authorization states which AS may originate a prefix; an Internet Routing Registry route object expresses routing intent; and live BGP shows what networks are actually announcing and observing. Agreement is valuable, but no one record replaces the others.
RPKI origin validation can classify an announcement as Valid, Invalid or Unknown. It validates the prefix and origin relationship, not the full AS path, cloud service binding, application health or business ownership. A green RPKI result is therefore an important gate, not a completion certificate.
An exit-ready migration is designed before onboarding. It records the current and future origin AS, ROA and route-object owners, adjacent DNS and security dependencies, overlap rules, external observations, rollback triggers and the exact order for retiring the old origin.
The practical cost of BYOIP is not just a provider feature. It includes registry access, routing expertise, change supervision, monitoring, coordination with outside parties, evidence retention and the discipline to keep an old path available until the new one is independently observed.

The featured image is an original photorealistic editorial scene of an unidentified network operator rehearsing a generic routing handover between two unbranded devices. It does not depict OVH US LLC, OVHcloud, RIPE NCC, ARIN, a real employee, customer, office, facility, network, address block, incident, outage, weakness or endorsement.

The familiar address can hide an unfinished move

Imagine a regional wholesaler with a customer portal, an API used by delivery partners and an outbound mail system. Several large customers have allowlisted the company's public IPv4 range. The addresses also appear in fraud rules, monitoring systems, firewall policies and old support documents. Renumbering every dependency would take months, so the business chooses a cloud service that lets it bring its own IP range.

At first, the decision feels reassuring. The portal will keep the same addresses. Partners do not need to edit allowlists. The mail team hopes to preserve the reputation attached to the range. Management hears that the move is reversible because the company keeps its addresses.

The team completes the provider onboarding steps and sees the range in a control panel. A regional registry still shows the organisation's number resources. A Route Origin Authorization, usually shortened to ROA, exists. An Internet Routing Registry route object also exists. The project plan marks “network complete.”

But those records answer different questions. The regional registry says which organisation has an administrative relationship to number resources. The ROA says which autonomous system is authorised to originate a route for a prefix. The route object records intended routing policy in an Internet Routing Registry. None of them, by itself, proves that the intended route is visible, that traffic reaches the correct cloud service, that the application answers, or that a return to the old provider would work.

The danger appears at the second move. The wholesaler wants to leave. It asks the new provider to announce the same range, but the old provider's origin remains authorised. An old route object still points to the old origin. A customer-controlled ROA has a maximum-length setting that does not cover the exact announcement. The old provider withdraws before the new route is visible from enough external networks. A project designed to avoid renumbering has become a routing incident caused by an incomplete authority handover.

This scenario is generic. It is not a report of an OVHcloud customer event. Its purpose is to show why portability has to be treated as an operating system, not a product label. A business can retain the numerical addresses and still lose reachability if the authority records, provider state and running routes do not move in a controlled order.

What the OVH US LLC directory record establishes

The BTW directory links this article to OVH US LLC. RIPE NCC's public member directory lists OVH US LLC under the United States and provides administrative service-area context. The record matters because it anchors a specific entity name in a public coordination system for internet number resources.

The record does not provide a complete network map. It does not name a particular ASN or prefix for this article. It does not prove that OVH US LLC operates a certain route, campus, cloud product or customer service. It says nothing about capacity, reliability, support response, pricing or the result of a migration.

That boundary is especially important with a familiar international brand. OVHcloud publishes global and regional product material. A branded page may describe a service available across several regions, while legal entities, contracts, facilities and operating responsibilities vary. This article does not collapse OVH US LLC, OVH SAS and every company using the OVHcloud brand into one legal or operational actor.

Instead, the member record is used for what it can establish: a named administrative presence in the RIPE system. OVHcloud's own pages are used to describe the branded BYOIP control surface. RIPE NCC, ARIN and IETF documents explain registry, RPKI and routing mechanisms. Claims stay attached to the source that can support them.

This is more than a writing precaution. The same discipline belongs in a migration. A procurement name, cloud account, resource holder, origin ASN, billing entity and network operator may be related without being identical. When a change is urgent, the team needs to know which party can authorise which action. A brand label is not an access credential and a member listing is not a router command.

The useful principle is modest: a registry is a ledger of defined relationships. It helps establish who can maintain or certify a resource. It does not dictate every fact about the running service. Operational truth still has to be observed in current route announcements and application behaviour.

BYOIP in plain language

An IP prefix is a block of addresses. A notation such as /24 describes the size of an IPv4 block. An autonomous system, or AS, is a network that presents a coherent routing policy to other networks. Its autonomous system number, or ASN, identifies it in interdomain routing. The Border Gateway Protocol, or BGP, is the system through which networks exchange announcements about how to reach prefixes.

In a conventional cloud arrangement, a customer normally uses addresses supplied by the provider. When the customer leaves, those addresses stay with the provider and the customer must renumber services. BYOIP changes the arrangement: the customer brings an eligible range over which it has the required authority, and the provider announces that range for services hosted on its platform.

OVHcloud's current public BYOIP page says customers remain the holders of the ranges they bring while OVHcloud announces them and routes them to eligible services. The page frames continuity, address reputation and reversibility as benefits. It says the service supports ranges registered with ARIN, APNIC and RIPE, offers a Bring Your Own AS option, and can provide optional reverse-DNS management. It also describes limits such as IPv4-only support, block-size rules and region constraints. These details must be rechecked against the exact product and contract at the time of a real purchase.

The product page also says an imported range can be moved to a non-OVHcloud service later. That is the promise an exit-ready plan should translate into testable controls. “We remain the holder” should become evidence of resource-certificate authority and registry access. “The provider announces it” should become an exact origin-AS plan. “We can move it elsewhere” should become a rehearsed sequence for authorising a new origin, verifying the new route, withdrawing the old one and cleaning up obsolete records.

OVHcloud's help material describes a guided onboarding process. A customer selects the RIR that manages the block, chooses a region, enters the range and chooses whether the OVHcloud AS or the customer's own AS will advertise it. That choice is not a decorative setting. It changes which ASN must appear in the ROA, route object, monitoring baseline and exit plan.

For a non-specialist, think of a retail lease. The company may own its brand and inventory while a shopping centre provides the building and public entrance. A registry record resembles the ownership paperwork. A ROA resembles a signed instruction saying which entrance is authorised to receive deliveries for the business. An IRR object resembles a directory entry used by logistics planners. BGP is the delivery network actually sending vehicles to an entrance. The shop is open only when the paperwork, directory, road signs and working doorway agree.

The analogy has limits, but it highlights the central point: keeping the same address numbers does not keep the route alive automatically.

Four layers of evidence must not be merged

The first layer is number-resource registration. A regional internet registry coordinates the allocation and registration of IP address space and AS numbers. The relevant organisation needs current access, responsible contacts and any agreements required to manage the resources. Registration helps establish administrative authority. It is not a real-time view of BGP.

The second layer is RPKI. Resource Public Key Infrastructure lets a holder of certified address space create a signed ROA. RFC 9582 describes a ROA as an object that identifies an origin AS and one or more prefixes, with an optional maximum length. A relying party can validate that signed material and provide validated ROA payloads to routers or policy systems.

The third layer is the Internet Routing Registry. A route or route6 object normally combines a prefix with an origin AS and other routing-policy metadata. RIPE Database documentation explains the object structure and the authorisation required to create route objects. Network operators often use IRR data to build filters. The record is useful, but it is not cryptographically identical to a ROA and it does not prove that a route is live.

The fourth layer is running BGP. A provider configures routers to originate or propagate the route. Other networks receive the announcement according to their sessions and policies. Collectors and looking glasses can observe parts of that distributed system. An application then has to be correctly bound behind the advertised address.

These layers can disagree. A holder can own a prefix but have no ROA. A ROA can authorise an AS that is not currently announcing. An IRR object can contain an old origin. BGP can carry an announcement that is RPKI Invalid. A route can be visible while the application is attached to the wrong service. Each mismatch has a different owner and remedy.

The evidence should therefore be stored with labels. “Registered holder checked at 10:00 UTC” is different from “ROA Valid in this validator at 10:05” and different again from “route observed by these external collectors at 10:10.” Application evidence might say “TLS and API check succeeded through the new address at 10:12.” Precise labels prevent a control-plane screenshot from being used as proof of user reachability.

This separation reflects how the internet actually works. Administrative records coordinate unique resources. Cryptographic objects express authority. routing databases publish intent. Routers execute policy. Applications consume traffic. Good operations connect the layers without pretending that one layer is sovereign over all the others.

A ROA authorises an origin; it does not switch traffic

RIPE NCC explains origin validation through three familiar states. A route is Valid when a matching ROA covers the prefix and authorises the observed origin AS within the allowed prefix length. It is Invalid when the origin is not authorised or the announcement is more specific than the permitted maximum length. It is Unknown when no covering ROA provides an answer.

Those states are important, but they are often overread. A Valid route is not proof that the holder wants every application behind the address to be available. It is not proof of the full BGP path. It is not proof that the cloud account has the right service binding. It does not authenticate the business using the application. It says the origin relationship matches the validated authorisation data.

An Invalid state is a strong warning, but the cause may be an operational mistake rather than hostile action. A team may have changed providers without updating the origin AS. It may announce a more-specific prefix than the ROA permits. A resource transfer or certificate change may have removed coverage. The response should be urgent and evidence-led, not automatically accusatory.

Unknown also needs care. It does not mean “safe” or “attacked.” It means the validated data does not contain a covering authorisation for the observation. Networks apply local policy to these states. RFC 6811 notes that validators and routers operate with distributed caches, so timing differences can produce different views during updates.

Creating a ROA therefore does not press a global route switch. The object is published through an RPKI repository. Validators fetch and validate data. Routers or policy systems consume the resulting records according to local schedules and policy. ARIN's FAQ describes repository and ecosystem timing rather than promising a single instant of universal effect.

During a migration, the team should record at least four times: when the ROA change was submitted, when the RIR showed it active, when selected validators exposed the expected payload, and when external route observations showed the intended origin. The intervals will vary. The plan should not withdraw a working origin simply because the first timestamp exists.

Origin AS and maximum length are small fields with large consequences

The origin AS in a ROA must match the AS that will originate the announcement. OVHcloud's BYOIP material says a customer can choose an OVHcloud AS or bring its own AS. A business that selects one option during onboarding and later changes the design must treat that as an authority migration, not a minor control-panel edit.

If the old provider originates the prefix from one ASN and the new provider will originate it from another, the holder may need a period in which both origins are legitimately authorised. ARIN's FAQ explains that each ROA contains one origin AS and that additional ROAs are needed for multiple origin ASNs. Whether an overlap is appropriate depends on the routing design, provider process and risk review. It should not be improvised during an outage.

Maximum length is the other easily misunderstood field. A ROA can authorise an aggregate prefix and specify how specific an announcement may be. For example, a holder might have a larger block but announce it as several smaller routes. If the maxLength is too restrictive, legitimate more-specific announcements can become Invalid. If it is too broad, the authorisation covers more-specific announcements than the operating plan needs.

ARIN's best-practice guidance recommends exact matching ROAs for prefixes actually announced and cautions against unnecessarily broad maximum lengths. The reason is practical. A broad authorisation may increase the set of routes that appear valid if a mistake or unauthorised event occurs under the permitted origin. A narrow setting reduces that surface but demands accurate planning for traffic engineering and failover.

Non-specialists do not need to calculate every subnet. They do need to ask a clear question: “Does our signed authorisation describe the exact prefixes and origin AS numbers that our providers will announce in normal operation, transition and rollback?” If the answer depends on a spreadsheet no one owns, the migration is not ready.

Route objects are useful intent records, not live-route proof

RIPE Database documentation describes route and route6 objects with a prefix and origin AS as key fields. Creating a route object requires defined authorisation, including control related to the address space. These controls make the database useful as an Internet Routing Registry.

Many networks use IRR data to generate or review filters. A correct route object can therefore affect whether an announcement is accepted by parts of the internet. During BYOIP onboarding, providers may ask for route-object changes or create operational expectations around them.

But an IRR object is not a ROA. The RIPE documentation notes its own authorisation model, while RPKI uses resource certificates and signed objects. A route object can exist without a matching ROA, and a ROA can exist without a particular IRR object. Their scopes and trust mechanisms differ.

Neither is the route itself. A stale route object can remain after a provider change. A newly created object can appear before routers announce anything. An object can contain the intended origin while a configuration mistake sends the live route from another ASN.

The migration checklist should therefore include three separate comparisons: intended prefix and origin, IRR prefix and origin, and validated ROA prefix, origin and maximum length. A fourth comparison checks the origin seen in BGP. The team should save the observation time and source for each.

The RIPE Database REST API documents how route objects can be queried with a combined prefix and origin key. That makes repeatable checks possible, but automation should still fail safely. A missing or unexpected record should stop an irreversible step and produce a specific exception. It should not silently choose the nearest-looking object.

Exit readiness begins before the first announcement

The cheapest time to design an exit is before the address range enters the new provider. At that point, the existing route still works and the organisation can resolve access gaps without an outage clock running.

Start with authority. Record the resource holder, the RIR account, the resource certificate, approved administrators and recovery contacts. Confirm whether the range is directly held or comes through an upstream party. ARIN's BYOIP guidance explains why this matters: an organisation using reassigned or reallocated space may not be RPKI-authoritative and may need its upstream provider to create a ROA.

Next, record the exact provider relationship. Which legal entity signs the contract? Which branded service is being used? Which support team handles onboarding and withdrawal? Which origin ASN will announce the range? Which region can receive it? OVHcloud's public page states that a block can be used in one region at a time and moved within defined constraints. A real plan must confirm the current rules for the bought service.

Then record every routing object. Save the current ROAs, maximum lengths, IRR route objects and actual origins. Identify who can create, edit and remove each item. If an outside connectivity provider manages a route object, its ticket lead time belongs in the project schedule.

Build the external baseline before the move. Observe the current origin from several independent perspectives. Record typical route visibility and the application checks that work through the prefix. The purpose is not to claim universal visibility. It is to have a dated comparison for the transition.

Finally, write the reverse sequence. What must be true before the new provider may announce? What must be observed before the old provider may withdraw? How long can both paths coexist? Which ROA or route object remains during rollback? When may obsolete authorisation be removed? A plan that documents only onboarding is not portable; it is merely installable.

A practical migration runbook

The following runbook is a generic operating model. It is not an OVHcloud implementation guide and does not promise that every product or contract permits every transition pattern.

Phase one is preparation. Confirm the eligible IPv4 range, RIR authority, resource-certificate coverage and account access. Record the intended provider origin ASN or customer ASN. Verify that the exact prefix size and region meet the current service requirements. Confirm that no unpublished transfer, dispute or certificate change will alter authority during the window.

Phase two is record design. Write the expected ROA entries, including prefix, origin and maximum length. Write the expected IRR route objects. Compare them with the provider order. Have a second qualified operator review the values character by character. A wrong ASN can be syntactically valid and operationally disastrous.

Phase three is adjacent dependency inventory. List authoritative and reverse DNS, certificates, firewalls, allowlists, geolocation feeds, abuse contacts, monitoring, rate limits, email reputation, partner contracts and any licence tied to an address. Keeping a prefix reduces renumbering work, but it does not eliminate the need to check how the new route and platform affect those systems.

Phase four is provider onboarding without customer traffic. Complete the provider's documented steps. Confirm which origin it will use and what signal indicates readiness. If a BGP-related feature is labelled alpha or not intended for production, as OVHcloud's separate BGP Service guide currently states, keep it outside a production dependency unless the status and risk are explicitly re-evaluated. A marketing page and an experimental feature are not the same thing.

Phase five is authority publication. Create or update the required ROA through the appropriate RIR or delegated RPKI system. Create or update the required IRR object through its authorised maintainer path. Do not remove the old valid state until the transition design says it is safe. Record the time and exact values.

Phase six is validation before traffic. Check the RIR view, selected relying-party or validator output, IRR records and provider state. Confirm that the intended transition announcements will be Valid rather than Invalid. If there will be a legitimate multi-origin overlap, verify that each origin has the required authorisation and that monitoring can distinguish them.

Phase seven is a bounded announcement. Ask the provider to announce according to the approved plan. Observe external BGP from more than one vantage point. Check origin, prefix length and visible path. A single provider dashboard is not an independent observation.

Phase eight is service attachment. Confirm that traffic reaching the new platform is bound to the right load balancer, firewall, server or application. Test TLS, HTTP, APIs and any protocol that matters to the business. Use the real hostname and expected security checks. A visible route to an unbound address is still an outage.

Phase nine is controlled traffic movement. Shift traffic only after authority, routing and application gates pass. Keep the old path available where the design permits. Monitor error rates, latency, connection distribution, mail or API behaviour, support contacts and security alerts. Use written thresholds rather than confidence.

Phase ten is retirement. Withdraw the old origin only after the new origin has been independently observed and the rollback owner agrees. Remove obsolete route objects and ROAs only when they are no longer required for normal service or rollback. Clean up old platform bindings, firewall rules, credentials and monitoring references. Save a final evidence pack.

Every phase needs an owner, deadline and stop condition. “Network team” is not an owner. Use a named role that is staffed during the window and has an escalation path.

Rollback has to restore reachability, not just stop change

A rollback button can mean several things. It may cancel a pending order, stop new configuration changes, withdraw a new route, re-advertise an old route or move an application binding. These actions are not interchangeable.

Suppose the new route is visible and RPKI Valid, but the application platform is returning errors. Withdrawing the new route might send traffic back to the old provider if the old route and service are still healthy. If the old provider has already withdrawn, deleted its service binding or revoked access, the same action can leave no working destination.

Suppose the new route is RPKI Invalid because the origin ASN was entered incorrectly. Reverting the application does not fix routing. The team may need to correct the ROA, change the announcement or restore the old origin. Each option has different propagation and cache timing.

Suppose both origins are visible unexpectedly. Traffic may take paths the team did not anticipate. A rollback needs to define which origin should remain, which party withdraws first and how external observations confirm convergence. Telling both providers to “undo” at the same time can create a gap.

An exit-ready plan therefore defines recovery states, not just commands. “Old path restored” should mean the old origin is visible, authority records permit it, the application is attached, external tests pass and critical residual traffic is understood. “New path removed” is only one part of that state.

Rollback also needs time. RPKI repositories, validators, routing systems and application caches do not change everywhere at one instant. The organisation should budget an overlap window that reflects its risk, provider processes and observed behaviour. The old service should not be destroyed to save a few hours of cost if doing so removes the only tested recovery path.

Adjacent records can break even when the prefix stays the same

BYOIP is attractive because many outside references can remain unchanged. The public prefix does not need to be replaced in every allowlist. Customers may keep the same endpoint address. Reputation systems continue to see the same numbers. Yet the surrounding operating environment can still change.

Reverse DNS may be managed through the new provider or through a delegated process. OVHcloud's public BYOIP page lists optional reverse-DNS management. The team should confirm whether existing PTR records remain, who can change them and how they are verified. A stable IP with a changed reverse name can still surprise mail and security systems.

Forward DNS may not need an address change, but health checks, traffic steering and certificates can change. A load balancer on the new platform may require a different validation method. Certificate automation may depend on an old account or challenge path.

Geolocation and reputation feeds may not immediately understand the new operating context. The address remains the same, but external systems can associate it with a different network or location based on routing observations. The article does not claim a universal update process; it identifies this as a dependency to test with the parties that matter.

Abuse and security contacts need review. The resource holder, cloud provider and application operator may each control different parts of an incident response. A report that reaches the wrong queue can delay correlation even when the address is correctly registered.

Monitoring needs two layers. Route monitoring checks prefix visibility, origin and validation state. Service monitoring checks the application through the public path. A route can remain healthy while the application fails, and an application can look healthy from inside the provider while the public route is missing.

Keeping the address is therefore continuity assistance, not continuity itself. It removes a large class of renumbering changes but leaves authority, routing, platform and organisational work.

A worked example for a non-specialist team

Consider a 60-person software company that directly holds one eligible public IPv4 block and currently uses its own ASN through a colocation provider. It wants to move customer-facing services to a cloud BYOIP offering while keeping the same origin ASN through a supported arrangement. This is a hypothetical example, not a description of OVHcloud implementation details.

The company begins with a one-page ledger. The resource row names the RIR account and certificate owner. The route row lists the prefix and current origin. The ROA row lists the same prefix, origin and maximum length. The IRR row lists the matching route object and maintainer. The service row lists the current application endpoint and new cloud binding. The observation row records external route and application checks.

Before the window, two operators compare the planned cloud order with the ledger. The security lead confirms that the ROA already authorises the exact announcement. The network lead confirms the route object. The application owner deploys and tests the service through a controlled path. The old platform remains intact.

During the window, the new provider begins the approved announcement. The network lead observes the prefix from multiple external points and confirms the intended origin. The security lead checks the RPKI state. The application owner tests TLS, login, API calls and a synthetic transaction through the public address.

Traffic is moved in a small cohort. Monitoring shows both network and application signals. If the route is Valid but the application error rate crosses the written threshold, the team restores the old service binding or route according to the runbook. It does not waste time debating whether “RPKI is green” means the application must be fine.

After a stable observation period, the company retires the old platform. It checks reverse DNS, monitoring, credentials, firewalls and incident contacts. It saves the final record set and schedules a quarterly exit rehearsal.

Now imagine the company later changes to a provider with a different origin ASN. The ledger makes the difference visible. A new ROA may be needed. An additional route object may be needed. The new provider must be observed before the old origin is withdrawn. Obsolete authority should be removed after the transition, not left indefinitely.

The example works because every statement has an evidence type. Administrative authority comes from the registry. Origin authority comes from the ROA. routing intent comes from the IRR. route execution comes from BGP observations. application success comes from tests. The team is not asking one green light to prove five things.

Common failure modes and their business cost

The first failure is missing authority. A company believes it owns a range but discovers that an upstream provider controls the resource certificate. It cannot create the required ROA on schedule. The cost includes delayed migration, emergency coordination and possibly continued payment for the old service.

The second is the wrong origin ASN. A provider order, ROA and route object disagree. The route may be Invalid or filtered. The business sees an outage even though every team can point to a record that looks individually complete.

The third is an incorrect maximum length. The aggregate is authorised, but the provider announces more-specific routes outside the permitted value. The failure may affect only some prefixes or regions, making diagnosis harder.

The fourth is stale IRR data. Some networks build filters from an old route object and reject or delay the new announcement. The route appears from certain vantage points but not others. A single external check misses the partial reachability.

The fifth is early withdrawal. The old provider stops announcing before the new route is broadly observed. The organisation has converted a planned handover into a gap with no working origin.

The sixth is a false rollback. The project reverts a control-panel setting, but the old application or route has already been removed. The action stops the new path without restoring the old one.

The seventh is service detachment. BGP correctly delivers traffic to the new provider, but the address is attached to the wrong project, firewall, load balancer or tenant. Network monitoring reports success while customers see errors.

The eighth is incomplete cleanup. Old ROAs, route objects, provider accounts, credentials or reverse-DNS settings remain after the move. The records no longer describe intended reality and enlarge the future error surface.

The ninth is entity confusion. A team contacts the familiar brand without knowing which legal entity, support queue or operations group owns the actual resource or service. Valuable incident time is lost establishing responsibility.

The tenth is evidence without time. A screenshot proves that a state existed, but no one knows whether it was taken before or after the change. Routing and registry data are time-sensitive; an undated record can mislead the next operator.

These failures have human costs. Staff work overnight, partners lose access, support teams handle duplicate tickets, sales teams explain uncertainty and leaders make decisions with incomplete evidence. The feature fee may be small while the coordination cost is substantial.

A responsibility matrix that exposes the gaps

Resource authority: The number-resource owner maintains the RIR account, agreements, certificate coverage and approved administrators. Evidence is a current resource and access review. Failure mode: no one can make the required signed change.

ROA authority: The RPKI owner defines prefix, origin and maximum length and manages publication. Evidence is the validated payload observed through selected tools. Failure mode: a legitimate route becomes Invalid or remains Unknown against policy.

IRR authority: The routing-policy owner maintains route objects and knows the maintainer path. Evidence is a current object query. Failure mode: filters reflect stale intent.

Provider routing: The cloud or network provider executes the approved announcement and withdrawal. Evidence is provider confirmation plus independent BGP observation. Failure mode: intended state and running routers diverge.

Service binding: The application platform owner attaches the address to the correct service and tests the public path. Evidence is protocol-level checks. Failure mode: a healthy route reaches an unhealthy or wrong application.

DNS and identity: The domain or messaging owner maintains forward and reverse DNS, certificates and mail controls where relevant. Evidence is external resolution and application-specific results. Failure mode: the address is reachable but operational identity is inconsistent.

Monitoring: The operations team observes route state and application state separately. Evidence is time-stamped alerts and dashboards with defined vantage points. Failure mode: one healthy layer masks another failed layer.

Change control: A named coordinator holds the sequence, stop conditions and rollback decision. Evidence is an approved runbook and event log. Failure mode: simultaneous actions remove both recovery paths.

Procurement and legal: The contract owner records the actual service entity, region, terms and exit obligations. Evidence is the current order and support path. Failure mode: the team assumes a branded promise applies to a different product or entity.

Leadership: The accountable executive funds overlap, rehearsal and cleanup. Evidence is an accepted risk decision. Failure mode: cost pressure removes the safe transition window.

If a row has no owner, it is not a minor documentation problem. It is an unassigned control in a production migration.

A 30-day readiness programme

Days one to five: identify critical public prefixes and the business services behind them. Record the RIR, resource holder, certificate coverage, current origin AS, current ROAs, IRR route objects and external BGP baseline. Do not start with a provider shopping list; start with the resources that must survive.

Days six to ten: map access. Confirm who can log in to the RIR, RPKI system, IRR maintainer, current provider and proposed provider. Test recovery paths without exposing credentials. Remove dependencies on one personal account.

Days eleven to fifteen: write the intended transition state. Define normal, overlap, rollback and final origin AS values. Specify exact prefixes and maximum lengths. Add expected IRR objects and provider actions. Have an independent operator review the plan.

Days sixteen to twenty: inventory adjacent systems. Check DNS, certificates, mail, allowlists, firewalls, geolocation, abuse contacts, monitoring, backups and partner communications. Mark which dependencies truly remain unchanged because the address stays the same and which still need work.

Days twenty-one to twenty-five: rehearse in a safe environment or with a non-critical prefix where permitted. Measure how long authority records and external observations take to reach the expected state. Test the application path and rollback steps. Do not infer production timing from one rehearsal; use it to expose missing ownership and tooling.

Days twenty-six to twenty-eight: run a tabletop failure exercise. Give the team one scenario with an Invalid origin, one with a Valid route but failed application binding, and one with partial external visibility. Require a decision using evidence, not job-title authority.

Days twenty-nine and thirty: approve the production runbook. Name the change coordinator and rollback authority. Set the overlap budget, observation interval and cleanup deadline. Save a versioned evidence template.

At the end of the month, leadership should be able to answer: who controls the resources, which origins are authorised, what the routing databases say, what the internet currently sees, what application users receive, and how the old path can be restored. If any answer is “we will ask the provider during the incident,” the plan is not yet exit-ready.

A scorecard for buyers and operators

Entity clarity: Does the contract identify the actual service entity and region? Is the team avoiding assumptions based only on the OVHcloud brand or the OVH US LLC RIPE member record?

Resource authority: Can the organisation prove its ability to manage the relevant resource certificate or identify the upstream party that must act? Are at least two approved operators available?

Origin design: Are the provider AS or customer AS choices explicit? Do normal, transition and rollback states each have an authorised origin plan?

ROA precision: Do prefixes, ASNs and maximum lengths match the exact announcements? Has a second operator reviewed them? Are obsolete authorisations scheduled for removal?

IRR precision: Do route objects reflect intended routing? Is the maintainer access current? Are IRR and RPKI treated as separate checks?

External observability: Can the team see origin and visibility from multiple independent vantage points? Are observations dated and tied to a source?

Application proof: Are TLS, HTTP, API, mail and other business protocols tested through the public path? Is provider-internal health kept separate from user-path health?

Rollback integrity: Does rollback restore a complete working state, including route authority and service binding? Is the old path retained long enough to prove recovery?

Adjacent controls: Have DNS, certificates, reputation, allowlists, security contacts and monitoring been reviewed even though the address is unchanged?

Cleanup: Are old ROAs, route objects, accounts, credentials and platform bindings removed deliberately after the observation period? Is cleanup verified rather than assumed?

Evidence quality: Does every green status say what it proves? A member record proves membership context. A ROA proves signed origin authority. A route object records intent. A BGP observation records running state from a viewpoint. An application test records one user path.

The scorecard does not ask whether BYOIP is “good” or “bad.” It asks whether the organisation has converted portability into an observable, reversible operating process.

What the public sources cannot tell us

The sources do not map a specific ASN, prefix, route, customer, facility or cloud deployment to OVH US LLC for this article. The RIPE member directory is not used for that purpose.

The OVHcloud pages describe branded BYOIP capabilities and requirements. They do not prove that OVH US LLC is the contracting or operating entity for a particular customer, product or region. A buyer must confirm the exact current order and legal terms.

The sources do not show an actual OVHcloud customer's ROA, IRR object or BGP route. This article does not claim that a customer experienced an Invalid announcement, failed migration, outage or security incident.

The sources do not guarantee global propagation time. RPKI repositories, validators and routers operate on distributed schedules, and networks apply local routing policy. External checks are observations, not universal certificates.

The sources do not prove application availability, mail delivery, reputation, latency, DDoS protection outcomes or contractual performance. Routing authority and live routing are only parts of a service.

The OVHcloud BGP Service guide reviewed for this article labels that separate feature alpha and not intended for production. The article does not present it as a production dependency or infer future availability.

The sources cannot decide whether a particular transition should use multi-origin overlap, the provider's ASN or a customer ASN. Those choices require the exact service design, routing expertise, provider confirmation and risk approval.

The generated image is generic editorial context. It does not depict OVH US LLC, OVHcloud, RIPE NCC, ARIN, real equipment, a real migration or a real incident.

Finally, public documents cannot replace a current preflight. Registry access, certificates, product requirements, provider processes and live route state can change. A real migration must recheck each one immediately before an irreversible action.

Conclusion

OVH US LLC's RIPE member entry provides a bounded administrative anchor. OVHcloud's public BYOIP material describes a service in which eligible customer-held IPv4 space can be announced through a provider or customer AS while the customer retains responsibility for the addresses. That is enough to examine the control surface without inventing a company-specific route or customer result.

The central lesson is that portability has layers. The number-resource registry records administrative authority. A ROA signs the allowed prefix-origin relationship. An IRR route object records routing intent. BGP shows what networks are actually announcing. The application shows whether the service works. A safe move keeps these layers distinct and makes them agree through evidence.

RPKI is essential but bounded. Valid does not mean reachable, secure or healthy. Invalid can arise from a migration mistake. Unknown is not a verdict. Origin validation is one input into distributed routing policy.

An exit-ready plan starts before onboarding. It records authority, chooses the origin model, prepares precise ROAs and route objects, inventories adjacent systems, establishes external baselines, preserves a tested old path, moves traffic in bounded steps and retires obsolete state only after the new path is observed.

For a non-specialist leader, the decisive questions are straightforward. Who can sign the routing authority? Which network should announce today, during rollback and after exit? What do external networks currently see? Does the application work through that path? Who has the authority and time to restore the old state?

If those answers exist in a current ledger and a rehearsed runbook, BYOIP can support genuine portability. If they live only in a provider interface and institutional memory, familiar addresses may conceal a move that the organisation cannot safely reverse.

OVH US LLC in the RIPE Ledger: What Must an Exit-Ready BYOIP Plan Prove?

Why it matters