Interdomain Routing Tutorial

This paper discusses BGP, the mechanism used for making interdomain routing decisions. The basic assumption is that the network is interconnected by many autonomous systems (ASes) where their operation is driven by financial interests. The relation between two ASes can be a provider-customer relation where the provider is capable of providing global connectivity to its customers and charge a transit fee for that. Or the relation can be a peering type where two ASes form an “alliance” to avoid paying transit to their respective ISPs for traffic between them. Between ASes, the agreement to forward packets to a destination prefix is done through route announcements. BGP is the protocol used to exchange this routing information between border gateways. When announcing routes to different ASes, however, they are filtered so that it contributes to meeting their financial objective.

The design goals of BGP are to be scalable, be able to enforce various routing policies, and to promote cooperation under competitive circumstances. IGPs were not suitable for the job because it doesn't scale well and its inability to implement policies. The basic structure of a BGP announcement is an IP prefix followed by several attributes that can be used to implement routing policies. One important attribute is LOCAL PREF where an AS uses it to prefer routes announced by a customer to those of peers to those of providers. Of course this is because it is the profitable thing to do. Since generally, there are several BGP routers within an AS connected to several different ASes, there is a need to exchange routing information between the internal BGP routers so that they have a unified view of the outside. This is done by iBGP while the between-AS BGP is called eBGP. After comparing the attributes of several route announcements with the same prefix, the BGP router selects the next hop, writes it to its forwarding table and disseminates this to the other routers.

This was a good tutorial that provided background on the multi-tiered internetwork and used it to motivate the why BGP has particular features or attributes. It also explained well what goes on in a BGP session. On figure 4-7 with the route reflectors, I think the route reflectors should still maintain fully-meshed iBGP sessions with each other rather than a tree-like structure. Because if a route update comes from a client of R1, according to the update rule, R3 and its clients will not get the updated route. Also, the tutorial implies there can be BGP routers that don't have an eBGP session but only iBGP sessions. The only reason for having these kinds of routers should be that these have the potential to have an eBGP session with another but the inter-border link is temporary down.

BGP seems suitable for enforcing policies but since it has a rather simple route selection rule, it neglects to some extent the quality of service provided to its customers. This may be an area where there can be improvement in future research.