Internet transit provider
An Internet transit provider provides its paying customers with access to the default-free zone (DFZ) of the Internet, for fees usually based on the speed of the access link(s) to the customer. The transit provider will advertise the provider-independent (PI) address space of its customers to the DFZ, and usually will assign provider-dependent (PA) when requested by its customers.
Using the Border Gateway Protocol (BGP) provider will advertise, to its peers in the DFZ, the minimum number of CIDR blocks consistent with the multihoming and traffic engineering requirements of its own infrastructure and of its customers.
Minimal customer connectivity
It may speak BGP to its customers, although this is not needed when the customer's access to the Internet goes through a single link to a single transit provider. As long as the customer's routing system advertises the provider connection as the default route, and propagates the default in its interior routing system, BGP is not needed.
Customer multihoming to a single transit provider
If it provides several physical links to the same customer, and the customer uses PA address space from that single provider, it is usually advisable for the customer to use BGP to multihome to the different points of presence (POPs) of the transit providers, using the single-provider-multihoming technique of RFC 1998. At each of these POPs, the customer may advertise a preferred address block, with the remaining address space less preferred. By spliting the customer address space over several POPs, it achieves load-sharing traffic engineering among the links, but, by also advertising the entire address space as less-preferred, it achieves the fault tolerance of multihoming.
Customer multihoming to multiple transit providers
If the customer connects to more than one transit provider, RFC 1998 does not apply. When the customer has his own PI address space, both providers advertise the PI aggregates, and, when all parties agree to participate in load sharing, may advertise more-specific CIDR blocks as more-preferred through different providers.
When one transit provider supplies PA address space to the multihomed customer, for multiprovider multihoming to work, the second transit provider has to agree to advertise the CIDR block of PA address space assigned to the customer. Of course, the first provider has to agree to have part of its space advertised by another provider. Such arrangements should be defined in the Routing Policy Specification Language (RPSL), defined in RFC2622, and published in an appropriate routing registry. One of the providers may offer a routing registry for its customers, or the customer, perhaps having it done by BGP and RPSL experts at the providers, may record the policies in a registry. Most commonly, this will be the routing registry of the address registry that assigned the PI address space to the provider.
What does the provider advertise to the customer?
In a single-link situation, there is no reason for the provider to offer more than default. If there are multiple links to the same provider, it may be appropriate for the provider to announce his own customer routes to each BGP-speaking customer, so they can pick the best exit (see potato routing) to reach that destination.
When the customer connects to two providers, it is generally wise to accept at least customer routes of the provider, unless the customer router cannot handle the number of routes involved. Best exit routing from the customer will take place only if it accepts a full routing table from each provider, which may or may not be within the capabilities of the customer router.