Design principles of policy languages for path vector protocols

Timothy G. Griffin, Aaron D. Jaggard, Vijay Ramachandran
2003 Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications - SIGCOMM '03  
BGP is unique among IP-routing protocols in that routing is determined using semantically rich routing policies. However, this expressiveness has come with hidden risks. The interaction of locally defined routing policies can lead to unexpected global routing anomalies, which can be very difficult to identify and correct in the decentralized and competitive Internet environment. These risks increase as the complexity of local policies increase, which is precisely the current trend. BGP policy
more » ... nguages have evolved in a rather organic fashion with little effort to avoid policy-interaction problems. We believe that researchers should start to consider how to design policy languages for path-vector protocols in order to avoid routing anomalies while obtaining desirable protocol properties. We take a few steps in this direction by identifying the important dimensions of this design space and characterizing some of the inherent design trade-offs. We do this in a general way that is not constrained by the details of BGP. den risks. The interaction between locally defined routing policies can lead to unexpected global routing anomalies such as nondeterministic routing and protocol divergence [9, 26] . If the interacting policies causing such anomalies are defined in separate, autonomously administered networks, then these problems can be very difficult to debug and correct. For example, the setting of an attribute in one autonomous system to implement "coldpotato routing" can cause protocol divergence in a neighboring autonomous system [4, 18] . We suspect that such problems will only become more common as BGP continues to evolve with richer policy expressiveness. For example, extended communities [20] provide an even more flexible means of signaling information within and between autonomous systems than the original definition [3] did. At the same time, applications of communities by network operators are evolving to address complex issues of interdomain traffic engineering [2] . We believe that the root cause of "BGP-configuration problems" is a lack of design for the policy languages that are used to configure this protocol. BGP policy languages have evolved in a rather organic fashion with little or no effort made to avoid policy-interaction problems. We believe that researchers should start to consider how to design policy languages and path-vector protocols that together avoid such risks and yet retain other desirable features. We take a few steps in this direction by identifying the important dimensions of this design space and characterizing some of the inherent design trade-offs. We do this in a general way that is not constrained by the details of BGP. As a result, our framework may offer guidance not only in the analysis of proposals to correct or extend BGP but also in the analysis of other BGP-like protocols such as a version of BGP supporting Virtual Private Networks [22], Telephony Routing over IP (TRIP) [23], and of various proposals for interdomain routing of optical paths [19, 27]. Overview of the Design Space We feel that our main contribution is in the identification of the design goals of policy languages and pathvector protocols. In addition, we formalize these goals and path-vector implementations in a way that allows inherent trade-offs to be rigorously characterized. We identify six important design goals for any pathvector protocol and policy language: Expressiveness. From the perspective of a network operator, we desire policy languages that are as expressive as possible. For example, shortest-path routing is not expressive enough for the requirements of current interdomain routing because it is unable to capture the "natural" routing conditions arising from the pervasive economic roles of customer, provider, and peer [15, 16] . The challenge then is to design policy languages that are as expressive as possible, and yet not so expressive that other design goals are sacrificed. Robustness. We require predictability, i.e., that any nondeterminism in routing policies is not the result of unwanted policy interactions, and the existence of a routing solution which is always found by the protocol (this prevents protocol divergence). Furthermore, we insist that the same is true of any configuration that results from any combination of link and node failures in the network. The goal of robustness is the primary constraint on the expressive power of a policy language; we are generally uninterested in non-robust policies.
doi:10.1145/863961.863964 fatcat:nx6hntvpebfxfdog3ot2uvfuwy