LECTURE 4. INTERDOMAIN INTERNET ROUTING transit provider routes. Does an ISP want to provide transit to the routes exported by provider to it? Most likely not, because the isp isn t making any money on providing such transit facilities. An example of this situation is shown in Figure 4-4, where Cp is a customer of P, and P has exported a route to Cp to X. It isn,'t in X's interest to advertise this route to everyone, e.g., to other ISPs with whom X has a peering relationship. An impor- tant exception to this, of course, is X's transit customers who are paying X for service-the service X provides its customers Cis is that they can reach any location on the Internet via X, so it makes sense for X to export as many routes to X as possible Peer routes. It usually makes sense for an iSP to export only selected routes from its outing tables to other peering ISPs. It obviously makes sense to export routes to all of ones transit customers. It also makes sense to export routes to addresses within an ISP However, it does not make sense to export an ISP's transit provider routes to other peering ISPs, because that may cause a peering iSP to use the advertising ISP to reach a destination advertised by a transit provider. Doing so would expend isP resources but not lead to revenue. The same situation applies to routes learned from other peering relationships. Consider ISP Z in Figure 4-4, with its own transit customers. It doesnt make sense for X to advertise routes to Z's customers to another peering ISP(Y), because X doesn' t make any money on Y using X to get packets to Z's customers! These arguments show that most ISPs end up providing selective transit: typically, full transit capabilities for their own transit customers in both directions, some transit(between mutual customers)in a peering relationship, and transit only for ones transit customers (and ISP-internal addresses)to ones providers The discussion so far may make it sound like BGP is the only way in which to ex change reachability information between an ISP and its customers or between two ASes That is not true--a large fraction of end-customers(typically customers who don' t pro- vide large amounts of further transit and /or aren' t ISPs)do not run BGP sessions with their providers. The reason is that BGP is complicated to configure, administer, and man- age, and isnt particularly useful if the set of addresses in the customer is relatively in- variant. These customers interact with their providers via static routes. These routes are usually manually configured. Of course, information about customer address blocks will in general be exchanged by a provider using BGP to other ASes(ISPs)to achieve global reachability to the customer premises. 4.2.3 Importing Routes The previous section described the issues considered by an As(specifically, routers in an AS involved in BGP sessions with routers in other ASes) while deciding which routes to export. In a similar manner, when a router hears many possible routes to a destination network, it needs to decide which route to install in its forwarding tables This is a fairly involved process in BGP and requires a consideration of several attributes of the advertised routes. At this stage, we consider only one of the many things that a router needs to consider, but it's the most important consideration. It has to do with who advertised the route. Typically, when a router(e.g, X in Figure 4-4)hears advertisements to its transit customers from other ASes(e.g, because the customer is multi-homed), it needs to ensure that packets to the customer do not traverse additional ASes unnecessarily. This
6 LECTURE 4. INTERDOMAIN INTERNET ROUTING Transit provider routes. Does an ISP want to provide transit to the routes exported by its provider to it? Most likely not, because the ISP isn’t making any money on providing such transit facilities. An example of this situation is shown in Figure 4-4, where C! P is a customer of P, and P has exported a route to C! P to X. It isn’t in X’s interest to advertise this route to everyone, e.g., to other ISPs with whom X has a peering relationship. An important exception to this, of course, is X’s transit customers who are paying X for service—the service X provides its customers Ci’s is that they can reach any location on the Internet via X, so it makes sense for X to export as many routes to X as possible. Peer routes. It usually makes sense for an ISP to export only selected routes from its routing tables to other peering ISPs. It obviously makes sense to export routes to all of ones transit customers. It also makes sense to export routes to addresses within an ISP. However, it does not make sense to export an ISP’s transit provider routes to other peering ISPs, because that may cause a peering ISP to use the advertising ISP to reach a destination advertised by a transit provider. Doing so would expend ISP resources but not lead to revenue. The same situation applies to routes learned from other peering relationships. Consider ISP Z in Figure 4-4, with its own transit customers. It doesn’t make sense for X to advertise routes to Z’s customers to another peering ISP (Y), because X doesn’t make any money on Y using X to get packets to Z’s customers! These arguments show that most ISPs end up providing selective transit: typically, full transit capabilities fortheir own transit customers in both directions, some transit (between mutual customers) in a peering relationship, and transit only for one’s transit customers (and ISP-internal addresses) to one’s providers. The discussion so far may make it sound like BGP is the only way in which to exchange reachability information between an ISP and its customers or between two ASes. That is not true—a large fraction of end-customers (typically customers who don’t provide large amounts of further transit and/or aren’t ISPs) do not run BGP sessions with their providers. The reason is that BGP is complicated to configure, administer, and manage, and isn’t particularly useful if the set of addresses in the customer is relatively invariant. These customers interact with their providers via static routes. These routes are usually manually configured. Of course, information about customer address blocks will in general be exchanged by a provider using BGP to other ASes (ISPs) to achieve global reachability to the customer premises. ! 4.2.3 Importing Routes The previous section described the issues considered by an AS (specifically, routers in an AS involved in BGP sessions with routers in other ASes) while deciding which routes to export. In a similar manner, when a router hears many possible routes to a destination network, it needs to decide which route to install in its forwarding tables. This is a fairly involved process in BGP and requires a consideration of several attributes of the advertised routes. At this stage, we consider only one of the many things that a router needs to consider, but it’s the most important consideration. It has to do with who advertised the route. Typically, when a router(e.g., X in Figure 4-4) hears advertisements to its transit customers from other ASes (e.g., because the customer is multi-homed), it needs to ensure that packets to the customer do not traverse additional ASes unnecessarily. This
SECTION 43. BGP usually means that customer routes are prioritized over routes to the same network ad vertised by providers or peers. Second, peer routes are likely more preferable to provider routes, since the purpose of peering was to exchange reachability information about mu- tual transit customers. These two observations imply that typically routes are imported in the following priority order customer> peer> provider This rule(and many others like it)can be implemented in BGP using a special attribute thats locally maintained by routers in an As, called the LOCAL PREF attribute. The first rule in route selection with bGP is to pick a route based on this attribute It is only if this attribute is not set for a route, are other attributes of a route even considered. Note however, that in practice most routes in most ASes are not selected using the LOCAL PREF attribute; other attributes like the length of the AS path tend to be quite common. w discuss these other route attributes and the details of the BGP route selection process, also called the decision process, in the next section ■4.3BGP We now turn to how reachability information is exchanged using BGP, and how routing policies like the ones explained in the previous section can be expressed and enforced. We start with a discussion of the main design goals in BGP and summarize the protocol. Most of the complexity in wide-area routing is not in the protocol, but in how BGP routers are configured to implement policy, and in how routes learned from other ASes are dissemi- nated within an As. The rest of the section discusses these issues 4.3.1 Design Goals The design of BGP, and its current version (4), was motivated by three important needs 1. Scalability. the division of the Internet into ASes under independent administration was done while the backbone of the then internet was under the administration of the for BGP was to ensure that the Internet routing infrastructure remained scalable as the number of connected networks increased 2. Policy. The ability for each As to implement and enforce various forms of routing gn go opment of the BGP attribute structure for route announcements, and allowing route 3. Cooperation under competitive circumstances. BGP was designed in large part to handle the transition from the nsfnet to a situation where the" backbone"Inter net infrastructure would no longer be run by a single administrative entity. This structure implies that the routing protocol should allow ASes to make purely local decisions on how to route packets, from among any set of choices In the old NSFNET, the backbone routers exchanged routing information over a tree ology, using a routing protocol called EGP. (While the modern use of the term EGP
SECTION 4.3. BGP 7 usually means that customer routes are prioritized over routes to the same network advertised by providers or peers. Second, peer routes are likely more preferable to provider routes, since the purpose of peering was to exchange reachability information about mutual transit customers. These two observations imply that typically routes are imported in the following priority order: customer > peer > provider This rule (and many others like it) can be implemented in BGP using a special attribute that’s locally maintained by routers in an AS, called the LOCAL PREF attribute. The first rule in route selection with BGP is to pick a route based on this attribute. It is only if this attribute is not set for a route, are other attributes of a route even considered. Note, however, that in practice most routes in most ASes are not selected using the LOCAL PREF attribute; other attributes like the length of the AS path tend to be quite common. We discuss these other route attributes and the details of the BGP route selection process, also called the decision process, in the next section. ! 4.3 BGP We now turn to how reachability information is exchanged using BGP, and how routing policies like the ones explained in the previous section can be expressed and enforced. We start with a discussion of the main design goals in BGP and summarize the protocol. Most of the complexity in wide-area routing is not in the protocol, but in how BGP routers are configured to implement policy, and in how routes learned from other ASes are disseminated within an AS. The rest of the section discusses these issues. ! 4.3.1 Design Goals The design of BGP, and its current version (4), was motivated by three important needs: 1. Scalability. The division of the Internet into ASes under independent administration was done while the backbone of the then Internet was underthe administration of the NSFNet. An important requirement for BGP was to ensure that the Internet routing infrastructure remained scalable as the number of connected networks increased. 2. Policy. The ability for each AS to implement and enforce various forms of routing policy was an important design goal. One of the consequences of this was the development of the BGP attribute structure for route announcements, and allowing route filtering. 3. Cooperation under competitive circumstances. BGP was designed in large part to handle the transition from the NSFNet to a situation where the “backbone” Internet infrastructure would no longer be run by a single administrative entity. This structure implies that the routing protocol should allow ASes to make purely local decisions on how to route packets, from among any set of choices. In the old NSFNET, the backbone routers exchanged routing information over a tree topology, using a routing protocol called EGP. (While the modern use of the term EGP