The Network Peer Interface
Geoff Huston, July 1994
Copyright (c) Geoff Huston, 1994
The Network Peer InterfaceThis section examines the other boundary environment for the network service provider, which is that of the interface between the service provider and peer providers.
Such interactions generally have two major components: engineering and policy. The engineering issues will be considered here. The policy issues, including the issues of settlement, route determination, transit, and similar, fall under a broader agenda of policy determination, and are left outside the specific domain of this material.
The Network Peer Interface
- Routing Considerations
Export routes via BGP4 using CIDR
Import routes using whatever works easily!
- Operational Considerations
Minimise bandwidth used by routing
Maximise operational stability
The practical considerations within the network peer interface include the areas of routing management and operational coordination.
It is not intended to cover a comprehensive tutorial about various routing technologies, and their potential uses within the network peering environment. The current preferred interface technology for network peering within the Internet is to use the Border Gateway Protocol (BGP4) as the technology vehicle for the routing exchange. The preferred interaction method is also to aggregate routes as much as is feasible, presenting to the network peer entity a set of routes aggregated as CIDR blocks.
While the preferred vehicle for route advertisement is CIDR using BGP4, there is no strict requirement for the way in which routes are imported. Various route importation methods will be examined here, looking at the most appropriate domain of applicability.
In terms of operational considerations the network peer interface should (in theory) be a traffic conduit, and the bandwidth used by routing should be the minimum required to present a stable and accurate routing interaction environment.
This area can become quite complex, particularly when attempting to assert various policy constraints which are to be exported across the peer interface, or when attempting to engineer a more complex external interface which is intended to match the various policies of external networks, whether they are direct peers, or indirect peer entities. Such considerations are typically best considered within the exact context of the network in question, so no significant effort can be made here to cover the various design issues associated with such a domain.
Peer Interface Network Management
- Obtain registered Autonomous System number (AS) from IANA
- Generate aggregate mask which covers all announced networks
- Announce CIDR aggregate to peer via BGP4 session
There are a number of practical consideration relating to the management of the peer network interface. The first of these is the use of a duly assigned, unique, Autonomous System number (AS). The use of the AS within the network peer environment allows the collection of advertised networks to be administered in a single block using the AS as a tag. This allows the formulation of various transit and reachability policies to be implemented within the inter provider space by describing the interaction as a set of preferred and backup sequences of AS numbers (AS path) for the description of the policy-formulated traffic paths.
The second consideration is to generate a network advertisement block which covers all announced networks using a minimal set of network blocks. Within the routed Internet space the computation of comprehensive routing tables is becoming a task where the cost of the generation of the table is directly related to the number of individual advertised routing entries. The contentious effort by all service providers to aggregate atomic routing entries into larger CIDR blocks represents a considerable saving for the Internet as a whole.
Single Exterior Peer
- Announce local nets via CIDR aggregate using BGP4
- Synthesise static default route directed to exterior peer gateway
In the configuration where the network service is a stub network, and is not acting as a transit for any other network service provider, and where there is a single external peer interface, the network interface design is relatively straightforward.
The network service provider can announce the locally configured networks to the external peer via appropriate CIDR aggregation blocks, using a BGP4 session as the vehicle for the advertisement.
In this situation there is no requirement to import any routes from the peer network provider: the service provider can effectively synthesise a default route and direct this route towards the external peer network.
This results in the routing environment where all traffic internal to the network service provider is explicitly routed within the internal network infrastructure, and all traffic directed to any network which is not explicitly routed is directed towards the external peer gateway.
The explicit use of a distinct AS to tag all exported routes does allow the network to assert policies (or the absence of policies) across both the direct peer interface, and across distant peer interfaces, although the single peer model does imply that unless the peer entity possesses either matching policies, or implements a transit policy matching the local policy, then in the absence of either of these conditions the policies that are then exported by the peer network on behalf of the local network will be effectively the intersection of both policy sets.
Multiple Exterior Peers
- Externally Imposed Policy differentiation
For example:
Academic & Research peer external network
Commercial peer external network
- Routing is Destination address-based - not source address
Default route based on best policy match
Explicit routes are imported from other network peers
Traffic path based on destination net - not local source policy
Where the network service provider has multiple external peer interfaces the situation does become more complex.
A common configuration of multiple external peers is one where there are a number of externally imposed policy requirements, such as an external academic and research only network, and a commercial network, where there is a requirement to interact with both network providers, conforming to these external policy constraints.
Here the most reasonable design strategy is to configure a default external routing path to the network peer which provides the best policy match, and then explicitly import routes from the other peer network service providers as required.
An added complexity of multi-homed external links is where the national network provider wishes to explicitly advertise reachability for a subset of the locally routed networks through one external connection, and advertise the others via a second external connection. This generally implies the use of two AS numbers, and advertising via BGP4 the appropriate AS-defined network set across each external interface.
Multiple Exterior PeersWith this situation of multiple external peer connections must also be noted that multiple external links cannot be used in some form of load balancing configuration.
Viewed from an external network the routing choice made to reach the local network will be made on the destination network address and the forwarding table lookup within the external network's routing tables.
As noted above the only way to effectively present different reachability policies to the external connections within this configuration is to segment the local network according to the desired policy constraint, and advertise networks grouped within AS sets.
Multiple Exterior Peers
- Transit Arrangement
Importation of transiting AS network numbers
Announcement of transiting networks via AS path mechanism
A common configuration with multiple external peer networks is where the local network is acting as a transit for one network domain to reach the other domain.
For this to be configured the local network must import the transiting routes through explicitly configured AS numbers (or paths), and readvertise these routes with the same AS number (or paths), adding the local AS number to the AS path specification in the BGP4 advertisement.
Considerable care must be taken in such configurations to ensure that there is appropriate policy matching in such cases, and that neither external network's policies are compromised by this transit arrangement.
Exterior Peering
- Importing a default route is cost effective and highly efficient
as long as there is a suitable policy and capability match with the peer
- Default-less routing is expensive, time-consuming, and can be unstable
- Default-less routing allows greater levels of self-determination of policy -
with an operational cost
The above notes are a very brief summary of what can become within today's Internet an extraordinary complex area of activity.
The point stressed here is that the network designed has to exercise care to ensure that only sufficient complexity required to undertake the required task should be used, and in such case the use of a default route is a highly efficient configuration as long as the entity which is peering via the default path has an appropriately common policy set.
Configurations which do not rely on default are left in the situation of having to compute comprehensive reachability using dynamically and statically provided information - a task which is ill-advised for most Internet players. While default-less routing does allow greater levels of policy assertion within the immediate environment of peer network connections, it quickly becomes a very expensive and often unstable routing configuration.
Exterior Peering
- Use a simple model initially:
Single exterior peer
Derived default route
Announce CIDR aggregate to peer
The external peer environment suggested for the startup national network provider is therefore the adoption of a very simple initial model, using a single external peer network connection.
This single peer connection allows the local provider to service the external connectivity set through the use of a default route, and allows the advertisement of all local routes through a spanning CIDR block set announcement using BGP4 and an assigned AS number.
Some care must be exercised in the choice of an external peer that the peer has the necessary external reachability and transit arrangements to enable comprehensive reachability to the Internet domain, modulo any policy restrictions which the local network may wish to impose.
3. Engineering the Network - The Client Interface
4. Engineering the Network - External Peering
5. Engineering the Network - Infrastructure
7. The Operational Environment
GH, July 1994