72	ROUTING POLICY

preferred, which prefixes are preferred, and which neighbours are preferred. It also allows you to effectively copy routing information from one routing protocol to another in a controlled fashion. Routing policy can be applied to any routing protocol, although the actual details of what can be done with each different protocol vary. However, the main area in which routing policy is applied, and in which it gets potentially complicated, is in interdomain routing. It is here that the wrong choice among different approaches can cost your company the most money.

6.1.1 WHO PAYS WHOM?

While many engineers, myself included, try to avoid the gory details of how their company’s business is operated, the customer–supplier relationships between your network and the networks to which it connects exert a significant influence upon how you implement your policy. It is clearly in your company’s interests to pay as little as possible to its suppliers and to obtain as much money as possible from its customers. Routing policy can be a means to improve the ratio of money earned to money expended. This may sound terribly mercenary to some, but any company operating on any other basis will inevitably lose money and eventually fail.

6.2 IMPLEMENTING SCALABLE ROUTING POLICIES

Policy configuration can form a significant proportion of any configuration file in an Internet router. Scalable policies are those that can be easily designed, easily implemented, and easily understood. It is therefore the responsibility of the engineer designing policy to ensure that policies are both easily implemented and easily understood. This latter aspect is often overlooked. However, it is vital that any engineer subsequently looking at the policy does not have to spend hours to understand what the policy configuration is supposed to be doing or, more importantly, what it is actually doing.

Modular policy description features allow sections of policy to be created that are extremely generic and can be applied within other policies purely by reference. For example, many policies on your network devices may refer to all addresses within your network. If you create a prefix list, which contains all your internal network addresses, it can be reused in many policy elements. In addition, if you add more addresses to your networks, you merely have to change one prefix list on every routing device rather than changing every relevant policy on every routing device.

Modular policy description features are clearly an extremely desirable feature because they have the potential to help your company to reduce administrative costs. However, depending upon how the syntax is implemented by the vendor and used by the policy designer, there is a risk that it could introduce some complexity. Consider the following two pieces of code (both for JUNOS software but the concept is equally applicable to any other router vendors’ configuration languages) (see Table 6.1).