Internet Engineering Task Force A. Burness, Ed. Internet-Draft BT Intended status: Informational A. Ford Expires: January 8, 2009 Roke Manor Research Ltd, July 7, 2008 Uses of policy control in routing draft-irtf-burness-policy-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 8, 2009. Abstract When considering a new routing system, we need to ensure that it is able to meet the functionality requirements of the participant networks. One aspect that is frequently over-looked is that routing is rarely a simple matter of choosing a least-hop path. This document attempts to highlight some of the more common policy choices that are made. We expect that policies that are in common use today should be easy to implement with any new routing schemes. Any routing scheme make it possible or significantly easier to implement the harder policies would have an implementation advantage. Burness & Ford Expires January 8, 2009 [Page 1] Internet-Draft Uses of policy control in routing July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Uses of policy . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Cost Policy Choices . . . . . . . . . . . . . . . . . . . 3 2.1.1. Customer-peer-provider . . . . . . . . . . . . . . . . 3 2.1.2. Link costs . . . . . . . . . . . . . . . . . . . . . . 4 2.1.3. Network costs . . . . . . . . . . . . . . . . . . . . 4 2.1.4. Implementation . . . . . . . . . . . . . . . . . . . . 4 2.2. Quality of Service choices . . . . . . . . . . . . . . . . 5 2.2.1. Application QoS . . . . . . . . . . . . . . . . . . . 5 2.2.2. Load balancing . . . . . . . . . . . . . . . . . . . . 5 2.2.3. Failure management . . . . . . . . . . . . . . . . . . 5 2.2.4. Route diversity . . . . . . . . . . . . . . . . . . . 5 2.2.5. Implementation . . . . . . . . . . . . . . . . . . . . 5 2.3. Political choices . . . . . . . . . . . . . . . . . . . . 6 2.3.1. National Boundaries . . . . . . . . . . . . . . . . . 6 2.3.2. Business boundaries . . . . . . . . . . . . . . . . . 6 2.3.3. Security . . . . . . . . . . . . . . . . . . . . . . . 6 3. Observations . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Burness & Ford Expires January 8, 2009 [Page 2] Internet-Draft Uses of policy control in routing July 2008 1. Introduction When considering a new routing system, we need to ensure that it is able to meet the functionality requirements of the participant networks. One aspect that is frequently over-looked is that routing at the inter-domain (or indeed intra-domain) level is rarely a simple matter of choosing a least-hop path. This document attempts to highlight some of the more common policy choices that are made. Some are relatively simple to implement so that they are thought of as business as usual; some are relatively ineffective when implemented today, others so complex that they are only done in special cases. We define a policy choice as something that means the path with the lowest AS-level hop count is not chosen, although we seriously question if AS hop count is a sensible metric to be using as default. We expect that policies that are in common use today should be easy to implement with any new routing schemes. Any routing scheme make it possible or significantly easier to implement the harder policies would have an implementation advantage. Here we aim to consider what people try to do independently from how they try to achieve it today. In [Casear] they consider the ways in which many of the policies below can be implemented. Here, we make little distinction between implementations that today allow only in or outbound control. Some policies will be naturally bi-directional, but today may only be achievable in one direction. Longer term there may be a need to consider how the tussle between different policies could be identified and resolved. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Uses of policy 2.1. Cost Policy Choices 2.1.1. Customer-peer-provider Cost control is the predominate reason for policy control, with [Wang] suggesting that 99% of route choices reflect customer-peer- provider relationships. Typically, a customer route will have top preference, then a peering route and finally a provider route. This precedence represents the business relationships between administrative entities, and thus the directions of monetary flow (e.g. provider routes cost money, whereas the others do not). Burness & Ford Expires January 8, 2009 [Page 3] Internet-Draft Uses of policy control in routing July 2008 Although it is clear that customer-peer-provider relationships are key in route choices, in many cases this may not be the only policy associated with any particular choice of route. For example, there may be a number of customer routes that could be chosen, or many links to the same customer. Thus, one should not mistake the fact that most route choices reflect these relationships to mean that these are the only policies that are used today. 2.1.2. Link costs A second example of cost can be seen where a site may have a primary and back-up link where the back-up link may be relatively expensive. Another related possibility is that the different links have different time of day or bandwidth related costs. The costs of links can represent much more than money, however. While some back-up links may indeed be monetarily expensive, they could also have high latency and/or low bandwidth. Properties such as these will further increase the representative cost of the link. Links that forbid certain types of traffic are an extreme example of this. 2.1.3. Network costs A further example of a cost-related policy is in the hot and cold potato routing. In hot potato routing, packets are sent to the nearest available exit as routing inside the network is felt to be more expensive than exporting the packet. Cold-potato routing deliberately holds the packet for as long as possible. This is more of a policy control in the intra-domain rather than the inter-domain, although for transit networks it can impact on the export policy rules. This type of routing in particular highlights one of the issues with policy routing, specifically that the path traversed can be much longer than if no policies had been applied. This is an example of how different polices (in this case the operator and the user policy of shortest path) can work against each other. 2.1.4. Implementation On the whole, cost-related policies can be implemented with purely local information, although the interface between inter and intra- domain configuration may need to be carefully worked out and implementation still causes a load into the global routing system. Burness & Ford Expires January 8, 2009 [Page 4] Internet-Draft Uses of policy control in routing July 2008 2.2. Quality of Service choices 2.2.1. Application QoS One type of quality of service choice is the ability to use a low delay link only for specific types of traffic; either application based (for example voice), or source based (senior management). Such choices are essentially extensions of the cost-based policies, but on a per-flow basis. These choices exist due to the wide variety of link characteristics that exist today - and this is further evidence of the limitation of traditional hop-count metrics. 2.2.2. Load balancing Load balancing is another type of quality of service choice where multiple exit links are available. Load balancing in response to congestion across routes is typically hand-configured but ideally the load balancing should be done dynamically in response to congestion (whilst avoiding oscillations in the path). As well as load balancing to manage the load on links, this type of functionality might also be required to avoid over-loading specific routers. 2.2.3. Failure management This includes the use of a low performance link only if all other options have failed. Also, load balancing and equal cost multipath can be used to ensure that, because routers have multiple links available, the network is less impacted by failure and convergence delays. 2.2.4. Route diversity Another important QoS choice is that of trying to maximise availability through route diversity. This is achieved through selection of routes that are diverse at the router level (intra- domain) or at the AS level. AS-level diversity is mainly useful for stub ASes, because at the end of the network the alternative routes injected from different entrances can be used without needing to be exported. 2.2.5. Implementation Currently, QoS based choices are hard to implement, particularly if you wish to control how traffic comes into you. We can see this today in the approaches that some networks take to provide load balancing between links to two different AS by essentially route flapping! Burness & Ford Expires January 8, 2009 [Page 5] Internet-Draft Uses of policy control in routing July 2008 There are essentially five main difficulties in trying to apply QoS related policies o Inter-domain routing assumes you will only advertise one route; not multiple routes with different QoS characteristics o How to map traffic onto different routes (TOS / DCSP bits ?) o Any choices can only be made on local information, yet global information would be useful, as for example your choice of a low delay link may lead to a long delay route being used - i.e. knowledge of how every AS in the path behaves would be beneficial o Even where information exchange between AS takes place, it is difficult to prove that the information has led to the expected actions taking place as policies may conflict o Adding additional information to the routing system goes against the wishes of many operators who wish to keep as much information hidden as possible; it also goes against the needs of the routing system for information exchange and processing to be minimised for scalability reasons. 2.3. Political choices 2.3.1. National Boundaries This primarily involves either ensuring that data keeps within a specified (set of) country, or avoids transiting specified countries. This type of choice requires that the deciding network has visibility of the entire route and (in the current case) can map AS information to countries. 2.3.2. Business boundaries The nature of (non-cost related) business relationships also occurs here. An example would be an academic network which will not accept transit commercial traffic. 2.3.3. Security Specific AS may also be avoided if they are known to be a security risk or to have consistently poor performance. Another set of policy decisions may relate to how well trusted the information received is; for example a network may be configured to ignore route advertisements from certain directions if it has reason to suspect that route hijacking may have occurred. Route flap damping and aggregation may be used to improve the safety of a network by Burness & Ford Expires January 8, 2009 [Page 6] Internet-Draft Uses of policy control in routing July 2008 reducing computational load. 3. Observations We have observed a trend towards increased use of multi-homing and increased mesh density even at the very edges of the network. Smaller and smaller networks are using some type of prefix de- aggregation in order to implement forms of policy control. We expect this trend will continue, for example personal body networks are likely to have many access links, and may even provide transit services for friends who, for whatever reason, are unable to have connectivity. Whereever multiple route choices become available, policy control may be expected to follow. There appears to be an increasing desire for routing policy at the application, or flow, level. All the suggested uses of policy above have varying levels of desirability depending on the types of traffic in use. Network operators would ideally like to be able to apply policy at this level of granularity so as to make best use of the available connectivity. Furthermore, we also observe a trend for hosts to start to become involved in policy routing choices. Peer to peer applications are beginning to measure parameters such as jitter in order to create their overlay networks. This also means that in addition to current conflicts between network providers, there is conflict between the policies of the upper and lower layers which can lead to extremely inefficient or costly routing at the lower layers. Every aspect of policy discussed in the previous section plays a part in a larger trade-off undertaken by network operators. Cost policies may conflict directly with QoS or political policies, and thus there is never a straightforward reason for a particular routing choice. Whenever analysing the requirements placed on policy choices, it is important to remember this and not ignore the impact of a particular policy motiviation. We talk a lot about link choice, with a sort of assumption that the link is a simple affair whose characteristics are easily determined by the router. It is worth observing that the term link may actually cover a complex layer 2 network, or layer 3 tunnels. Lack of information about the lower layer can again lead to inefficient or costly use of the lower network. Policy control can be difficult implement, especially for in-bound data. There is limited ability to exchange information with your neighbouring networks, and it is particularly difficult to co- Burness & Ford Expires January 8, 2009 [Page 7] Internet-Draft Uses of policy control in routing July 2008 ordinate if you have multiple AS level connectivity. Despite the complexity, and with no guarantee of deterministic results, the use of policy control is growing all the time. This makes it clear to me that if multi-path exposure becomes normal, then policy control rather than efficient network usage is likely to dominate the choice of multi-path. If multi-path is obscured in some way, operators and users are likely to go to great lengths to recover the level of visibility they already have. Some degree of visibility of the full path seems to be important for many of these policies. Today, the AS route traversed (which can then be mapped to network owner or country) is used by a number of policies. To achieve other goals, we would need additional visibility of other path-level information. This need seems to run counter to the need to hide information in order to improve routing system scalability. For example, adding additional routes to BGP based upon QOS information for example has been proposed in the past and generally avoided due to the great increase in complexity of the routing system. 4. Acknowledgements Louise Burness is partly funded by [TRILOGY] , a research project (ICT-216372) supported by the European Community under its Seventh Framework Programme. The views expressed here are those of the author(s) only. The European Commission is not liable for any use that may be made of the information in this document. Specific thanks must go to Marcelo Bagnulo Braun, Iljitsch van Beijnum and Olivier Bonaventure who have given very valuable assistance. 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations . 7. References Burness & Ford Expires January 8, 2009 [Page 8] Internet-Draft Uses of policy control in routing July 2008 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [Casear] Casear, "BGP routing policies in ISP networks", 2005, . [Handley] Handley, M., "HLP a Next Generation inter-domain routing protocol", 2005, . [TRILOGY] "Trilogy Project", . [Wang] Wang, "Interring and characterizing internet routing policies", 2003, . Authors' Addresses Louise Burness (editor) BT BT Adastral Park Martlesham Heath, Suffolk UK Phone: +44 1473 646503 Email: louise.burness@bt.com Alan Ford Roke Manor Research Ltd, UK Phone: Email: Burness & Ford Expires January 8, 2009 [Page 9] Internet-Draft Uses of policy control in routing July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Burness & Ford Expires January 8, 2009 [Page 10]