Routing policy

The general idea of routing policy is that if a destination exists in the routing table (for interior routing protocols), it is accessible; if there are multiple routes to it, take the one with the lowest metric. Especially for BGP exterior routing, and in an increasing number of complex enterprise networks, the idea of policy enters: a destination may be reachable, but there may be reasons it cannot be used for certain kinds of traffic, or that it is preferred for other kinds of traffic.

At the most basic level routing policy, policies define the way in which routers, and system routers, offer connectivity to various definitions. Technically, they cover more than simple reachabilility and routing metric, but also cover economics, security, availability, and operational management. From an organizational standpoint, well-defined policies are the basis of agreement between business requirements and the implementation of networks that meet those requirements?

A classic example was the NSFNET, which had an Acceptable Use Policy (AUP) that it could be used only between academic and research institution. Assume the Magnificent Institution of Technology receives a packet, from the College of the Yard, which is destined for a beloved local pizza restaurant, "Pie Are Squared". Much as that restaurant has had research, sometimes spotted with tomato sauce, done over its tables, it does not meet the AUP for NSFNET. Conveniently, however, there is a local city network to which the Magnificent Institution connects, so it can send the packet there. In like manner, if a packet originated from PAS, it could go through a private link between the two local colleges, but not over the NSFNET.

How does a router know the additional, non-metric information that it uses to make policy decisions? In BGP, any route can be tagged with a BGP community, which is a label that identifies a group of one or more routes. Several interior routing protocols also have mechanisms to tag routes. This is a simple example of policy information; far more complex examples will be found in the global Internet.

Routing Policy Specification Language

Due to the complexity of real-world polices, the Routing Policy Specification Language (RPSL) was created to have a way to write unambiguous policies, such that they could be stored in a distributed data base. RPSL was designed to create a view of the global routing policy can be contained in a single cooperatively maintained distributed database to improve the integrity of Internet's routing.

Use by software

It is not intended to be a router configuration language, but open source tools, such RtConfig, exist for converting RPSL to the subset of a real router configuation language that evaluates whether policies apply to a particular route.

Various analytic tools work with a Routing Registry, or database of RPSL policies written by different autonomous systems, which can check, for example, if a route meeting certain policies is indeed available in the internet.

Extensibility

RPSL is an extensible language. Extensions recently were defined so it could express policies for IPv6 routes as well as multicast routes. There is absolutely no reason why RPSL could not be extended to express interior routing policies, except that doing so was outside the charter of the Internet Engineering Task Force (IETF) working group that created the language. For example, it would be a relatively simple extension to add language features that apply quality of service criteria to certain routes and exits.

Applications and tutorials

For a number of examples of use of RPSL for typical Internet Service Provider operations, see the IETF reference.. There is a tutorial on ISP operations, including analyzing customer multihoming and other requirements and specifying them in RPSL.

Transmitting policies

For many years, many instructors taught "BGP transmits policies", but that is really incorrect. Until the fairly recent addition of new BGP features, what BGP actually transmitted was the information to be used for decision mechanisms, inside the router, to make policy definitions. RPSL, which is not a real-time protocol, and either RtConfig or manual configuration, described the policies themselves.

The new mechanisms, generically called Outbound Route Filtering (ORF), are in a number of commercial and open source router code implementation, but are still a working paper in the IETF. When a router is configured to reject routes meeting certain criteria, it certainly can do so on its inbound interfaces, but those undesired routes will needlessly take up bandwidth on the inter-router link. ORF lets one router tell another about the routes it will reject, so the other router will filter them on output.