BGP Routing Policies in ISP Networks April 28, 2009

The paper describes common techniques used to implement BGP decision policy in boarder gateway routers. Because the BGP does not specify the decision process, a complex preference and filtering scheme as sprung up in the relatively simple path vector protocol. The use of route attributes allows ISP to implement custom routing policies as they see fit.

Routing decisions are therefore not always simply shortest path. The main contributions from this paper are descriptions of the ways in which ISPs (and enterprises) make use of these attributes, filtering, and tagging to achieve preferred decisions.

The authors describe that it is common for ISP to affect routing policy for business relationship purposes. A common technique is to set non-overlapping LocalPref values for each business entity. This allows specific routing to say customers over peers. Additionally, tagging is used to disseminate preferences internally while filtering the tags prevents external entities from receiving such information.

It is also common and perhaps necessary to adjust routing for inbound and outbound traffic according to quality of service and load balancing purposes. The routing attributes can be used here to affect import policy so that LocalPref values can be updated according to capacity.

Filtering community attributes is also used to limit amount of routing updates received and thus the routing table size. This is an important concern as it has direct consequences in terms of scalability.

Lastly, the authors describe how filtering on import can prevent invalid (malicious) routes from changing the routing table. Similarly, filtering on export avoids spreading infrastructure information to the rest of the network.

The main problem with this paper is that it assumes that any change to the BGP protocol is out of the question. While it may not be the focus of this paper, it seems that some discussion of how the protocol could be improved to better accommodate custom routing would be in order. Instead the authors focus on how the existing policy can be manipulated to provide routing policy flexibility.

I’d expect to see further work on the use of RPSL or other routing policy languages in Internet level experiments. It would be nice to see how much better a routing policy language can be as compared to the current methods of policy implementation.

BGP Routing Policies in ISP Networks April 28, 2009

With the internet quickly evolving into a vast global network owned by several administrative authorities, the implementation and maintenance of various routing policies have become increasingly complex. The paper describes the various goals that the operators of ISPs have and their resulting routing policies. Most of the modifications to BGP protocols have been made using decision process to chose routes. The result is a protocol where most of the complexity is in the decision process and the policies used to influence decision is fairly simple. The policies can be broadly categorized into business relationship, traffic engineering and scalability. In the 1^st category, ISPs may want to prefer customer learned routes over routes learned from peers because sending traffic through customers generates revenue while sending traffic through providers costs money. The ISP can achieve this by assigning a non overlapping range of LocalPref values to each type of peering relationship. ISPs can also control route export to neighboring ISPs by tagging advertisements with a community attribute signifying the business relationship of the session, and filtering routes with certain community attributes when exporting to peers. In the case of traffic engineering, Operators can influence outbound traffic flow either by configuring import policies that affect which routes get in the set of equally-good border routers or by modifying the IGP link costs. One common goal is early-exit routing where ISPs forward traffic to the closest possible exit point hence avoiding congestion in its internal network. Load balancing can also be done by LocalPref to the outgoing links. Finally a properly configured set of BGP policies can improve the scalability of a network and its resilience to instability. For example one of the goals of an ISP is to protect itself from invalid route advertisements from an adversarial ISP which may lead to memory overflow and crashing of routers. This can be done by ignoring advertisements from peers with address spaces they don’t own and also by performing some sanity checks on the paths.

With the increasing complexity of policies, routers nowadays are much more weighted down with such policy enforcements which can make it subject to a variety of problems including misconfiguration, oscillations, and protocol divergence. The complexity of Internet routing makes it difficult to predict the way policies interact thus increasing the prevalence of configuration mistakes. Interdependencies of policy across ISPs can also trigger problems like persistent route oscillations.

The future directions of the work can include configuration checking tools that can avoid misconfigurations by verifying certain consistency criteria hold while modeling tools can predict side effects of configuration changes on routers within an ISP. Works can also attempt to coordinate route policies across ISPs without revealing private details of policies. Another important direction is to come up with some Routing Policy Specification Language (RPSL) which is vendor-neutral language for describing ISP policies. This will enable router configurations with higher level constructs that allow diverse policies while precluding certain misconfigurations. Finally new architectures like HLP can be explored which propose to expose the common policies that can be typically inferred in BGP today and optimize the routing protocol based on the resulting structure, with the aim to improve scalability and convergence of interdomain routes.

BGP Routing policies in ISP networks April 28, 2009

1. The paper provides a comprehensive overview of the BGP protocol used to achieve routing between ASs. It makes note of the major factors that influence inter-AS routing that aren’t an issue in intra-AS routing such as conflicting policies between different ASs, commercial aspects that define traffic between ASs, routing through intermediate ASs, etc. It talks of how BGP functions within an AS to allow its nodes to communicate with nodes in other ASs and also how packets that need to travel through multiple ASs before the reach their destination AS need to be handled. It makes note of the policies and the priorities of the policies that are used to determine routes in inter-AS communication.

2. It looks into the problem of a given AS wishing to influence the routing decisions of adjacent ASs when it has no direct control over the policies of its adjacent ASs. It talks of how an AS can make one route more preferable that another by suitably setting the MED attribute of the routers in the respective routes. It also talks of scenarios when it might be possible for an AS to remotely control the routing policies of a router in an adjacent AS.

3. It talks of how the overhead traffic generated due to the book-keeping involved in inter-AS routing can be reduced. Route-aggregation as a method to reduce the amount of information that needs to be communicated with a neighbouring AS when new nodes are added within an AS. An AS can configure its routers to advertise a single, less specific prefix to it’s neighbouring AS instead of advertizing two adjacent prefixes. Ignoring routes that change too frequently is another method of reducing the excessive traffic generated due to unstable routes.

Oversights:

The paper provides a concise overview of various aspects of BGP, ranging from the policies used in deciding routes to factors influencing these policies and how these policies can be used to control traffic between ASs. The topic is vast and there is no end to additional insights that can be given. It paper could have gone on and given a more in depth analysis of the BGP protocol and how it functions when the communicating ASs are not adjacent to each other or it could have looked into the short comings of BGP which include oscillations when routes change and how these shortcomings can be handled etc. However, there is no end to the detail that can be provided.

Future Work:

Some of the solutions provided by BGP are not the most efficient. For example the methods used by BGP to handel routes that go down or need to be taken down for maintence take up a lot of time and traffic before they reach a steady states. The various short commings of BGP can be looked into and methods can be suggested that circumvent the problem or provide more efficient solutions.

BGP Routing Policies in ISP Networks April 28, 2009

(i) The three most important things the paper says:

 

1) Routing policies is not a simple “shortest path” problem as the Internet grew.  It is now based on a myriad of factors, including but not exclusively economic, political, security and operational.  The paper effectively expands on the reasoning behind each one of these points.

 

2) It is difficult, if not impossible to ask every ISP to support a new routing design.  Therefore, the community of ISPs have opted to modify the “decision process” of routers instead.  That is why it is important to understand the “decision process” and not just simply change the protocol to support the limitations of the current system.

 

3) There is a delicate balance that each ISP has to play with neighboring AS. On one hand they need to depend on its neighbors routing information to make the best choice, but they also need to doubt everything that is provided.  This issue of trusting your neighbor really is root of BGP’s security, economic, and political concerns.

 

(ii) The most glaring problem with the paper:

 

This paper provides a lot of details of what settings to change and how it effects the decision process by the router.  However it never provides an overall perspective of how changing these settings work together.  For example, LocalPrefs is changed to support “business relationships”  and also changed to manage traffic.  The paper never addresses how this one setting can be configured in a way to satisfy the requirements from two directions.

 

(iii) The future research directions of the work:

 

It is obvious that with all the limitations of the current BGP framework, a new system is needed.  Perhaps instead of just simply working on a new protocol like HLP, some research should be done into how to propagated this new protocol.  And to go even further, how would an upgrade potentially disturb the QOS of the Internet as a whole.

 

BGP Routing Policies in ISP Networks April 28, 2009

i)

1. How packets are routed today on the internet is primarily a factor of different ISPs routing policies based on business concerns. I didn’t know business concerns effected packet routing to such an extent.

2.ISPs must balance the flow of traffic to/from their peers, customers, and bigger ISPs in order to maximize their profit. For instance an ISP might balance outgoing load across multiple exit points even if they are not the most ideal in order to not use a particular peer too much.

3. BGP can be used as a security mechanism to “blockhole” routes from spammers or Denial of Service attacks.

ii) I think the most glaring error of this paper was not giving an idea of how prevelent the different policies are and how the effect latency in the internet

iii) A future research direction would be to determine how these routing policies effect latency in the internet. It would be interesting to see if an overlay network could be build that dynamically monitored latency to other nodes in the network to build a routing network based on minimizing latency.

BGP Routing Policies in ISP Networks April 28, 2009

This paper starts with an introduction to BGP and AS routing and then focus on the decision process BGP uses to choose routes. There are several factors that influence ISPs to implement certain BGP routing decisions.

1. Business Relationships influence the decision process which cause ISPs to assign LocalPrefs to determine which peering relationship is more desired to be used to route traffic. Customers may be most preferred, while backup links may be least preferred. ISPs may also want to control route exports to other ASs by prepending a community attribute to advertisements from a peer, and filter for that attribute when advertising routes to other peers.

2. Traffic Engineering is also a factor in an ISP’s BGP policy when there may be several routes that are equally preferred. For outbound traffic control, one common goal is hot-potato or early-exit routing where the ISP forwards traffic to the closest border router to avoid internal congestion at the cost of inflating end-to-end path lengths on the internet. Another common goal is to reduce congestion on outbound links via load balancing by changing LocalPref for a set of prefixes that matches a regular expression with the help of tools. ISPs may also have inbound traffic control to limit internal congestion or control how much traffic it will receive from peers. One way of controlling inbound traffic is by AS pre-pending to artificially inflate the AS-path length. Another way ois to use the MED attribute. Traffic can also be remotely controlled by having an agreement between two AS’s to have community values map routes to a LocalPerf on a remote router. This is done because MED applies next AS hop  and LocalPref applies to routes across all neighbours.

3. Scalability is of concern to ISPs as well. There is a common goal of limiting the routing table size by utilising the community attribute and filters. Another goal is to limit the number of routing changes by flap damping to limit propagation of unstable routes.

4. Security is a big issue since an AS is highly vulnerable to false BGP updates. ISPs can defend themselves by filtering invalid routes, protect routing policies by overwriting attributes to expected values, securing the internal network infrastructure by export filtering, and blocking DoS attacks via damping and filters to direct spammer address blocks to blackhole routes.

I didn’t find any problems with the paper as it is just describing common design patterns of ISPs deploying BGP policies. The paper cites research topics done to improve BGP and further research can by done in serveral areas:

- Configuration checking and simulators to predict how policies will interact.

- Language design for a vendor neutral language to express routing policies.

- Research in an overhaul of BGP. BGP is not a clean protocol since there are many ambiguities associated with decision making.

BGP Routing Policies in ISP Networks April 28, 2009

(i) The three most important things the paper says:

1. BGP was introduced to allow ISPs to have greater control over route selection and propagation. It is an incremental, path-vector protocol. ISPs send updates for each prefix and updates to several fields may be advertised at once. Route selection is based on path length by default (when no policy exists), and via the BGP decision process in the presence of policy attributes. Using these advertised attributes (or purposely ignoring some of them), ISPs have the ability to choose particular routes, filter out certain routes, or add additional state to routes by tagging them with a community attribute.
2. The paper presents four distinct design patterns that are commonly used by ISPs to direct policy:
   • Business Relationships: ISPs generally have three types of business relationships — customer-provider, peer-peer and backup. The customer-provider relationship is the most desirable since this is how an ISP generates revenue. Furthermore, the ISP wants to suppress routes where traffic is forwarded from one provider/peer to another. These properties are achieved with attributes and tagging.
   • Traffic engineering: ISPs often want to be able to guide traffic to ensure optimal performance or guarantee some class of traffic quality/availability. ISPs use a number of techniques, such as hot-potato routing (so packets stay in the network for as short a time as possible) and load balancing.
   • Scalability: ISPs want to ensure that excessive updates are suppressed so that service quality and availability are not affected. This is achieved by capping the size of the routing table or suppressing unstable routes. ISPs try to send and receive a limited number of advertisements by using longer prefxes, imposing prefix caps and aggregating adjacent prefixes as needed.
   • Secuity: false information, either generated erroneously or injected maliciously, can be detrimental to performance. Some techniques used include sanity checks to eliminate invalid routes, overwriting unexpected attributes, filtering undesirable advertisements and putting limits on number of prefixes and session timeout.
3. There is a dense field of many policies which require support in BGP. This complexity leads to a variety of problems (such as misconfiguration, oscillations and protocol divergence) which could lead to degraded performance. Open research topics in the field include configuration checking (verifying that policies are consistent with each other), language design (creating a language that can be used to easily describe policy) and new architecture (which aims to simplify and extend BGP).

(ii) The most glaring problem with the paper:

A type of AS relationship not mentioned in the paper and which may have interesting implications for BGP policy is the sibling-to-sibling relationship. Siblings may be willing to share routes, which would not be done for providers or peers. Furthermore, there is no money gained or lost through routing traffic to a sibling, which may influence the decision process (we may choose a sibling over a provider but choose a customer over a sibling for instance).

(iii) The future research directions of the work:

The paper names some of the research directions that are currently being investigated (configuration checking, language design and new architectures). One thing about the BGP policies that concerns me is the fact that the policies of two or more ISPs may end up “butting heads”, perhaps unwittingly, and the ISPs’ performance might suffer as a consequence. It may be interesting to look into whether it was possible for a global or regional (i.e. on some subset of ISPs) tool could be devised to inform ISPs of the tradeoffs of their policies and to suggest possible modifications that would increase performance.

BGP Routing Policies in ISP Networks April 28, 2009

This paper just explains how BGP works on the internet. The point of the paper is the explain how BGP came to be and to describe patterns that ISPs use for policies to help understand what would be required to fix BGP or improve it.
Major Points of Paper:
1.) Scalability
Since bad information can be easily passed around ASs, BGP needs to be able to stop bad information from generating excessive updates that can trigger route instability. BGP uses filtering of long prefixes and community attributes to limit the routing table sizes. It also uses route aggregation to limit its advertisments to other ISPs. Lastly BGP uses flap damping to assign penalties that are incremented for any route that an update is received.
2.) Security
There are many different security goals ISP may have. The first is to stop their customers from learning bad routes. To do this the ISP checks  to make sure that updates are valid before sending them out. Other security problems include, stopping neighboring AS’s from influencing their routing decisions, stopping external routers from accessing certain information in the AS and DOS attacks. To deal with these an ISP can use import policies to delete or overwrite attributes,  filter bad AS advertisements and only accept a maximum number of prefixes before tearing down the session.
3.) Configuration
ISP’s have to deal with many different policies that can handle their business relationships and traffic. By using LocalPrefs and community attributes, ISP’s are able to control which routes their border router uses. They can make so that they send their packets to a neighboring AS A, but A cannot send its packets to this AS. This situation usually occurs when this AS pays A to send its packets it way. Traffic can be control by load balancing the traffic through many AS’s even if it is not the shortest route.

Glaring Problem:
BGP is a very complex protocol because of its general ability to apply policies. The problem with this is if bad information is given it require the AS’s  to be very smart to prevent bad information from messing up the routes the AS uses. It can be done but like earlier stated it is very complex and always changing.

Future Work:
With the patterns of BGP exposed, there will be more work on automating tools that support the BGP patterns that are mention in the paper. This paper also address more work on automated configuration checking, a policy language and new architectures.

BGP Routing Policies in ISP Networks April 27, 2009

This paper was primarily concerned with detailing BGP, or border gateway protocol, used by ISPs to influence the paths on which packets of different types are routed. It does not propose the actual idea, as it was well-established by the time that this paper was written but attempts to clearly describe BGP, the methods by which it influences routes, and the motivations for the different procedures implemented by the ISPs. The three major points that I took away from this paper were:
1. BGP policies can generally be broken down as being implemented for 1 of 4 general reasons: business relationships, traffic engineering, scalability, and security. These 4 considerations greatly impact how the policies are implemented as they require very different approaches and have very different goals in their design.
2. BGP can be extremely complex and the issue is further complicated because each implementer can do basically whatever they want without any kind of internet wide standard to worry about. This lack of standardization among the ISPs can lead to problems and degradation of customer service, scalability, and security if one of the ISPs decides to not play well with others.
3. BGP is something that has become necessary as the size of the number of nodes on the internet increased beyond what anyone had ever predicted. Intelligent control of packets within a group of nodes like an ISP provides valuable functionality and improved performance when implemented correctly. There are a number of things that can be done to improve the performance of the internet as a while using BGP or a similar protocol.
This biggest issue that I saw with this paper was the lack of discussion regarding the possible improvements to the system. However, this was an informational paper so that is to be expected. Slightly more discussion of what extensions could be useful or what standards have become commonplace (so as to be required implementation) would have added to the overall value of the paper.
Future research in this field is fairly obvious as it concerns making BGP more efficient, standardized and even extend it to provide more functionality. I feel that this final piece will become a fact due to increased security awareness and concerns. Improved security over the router system will add another layer of protection to every user and greatly complicate attackers jobs.