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 EGPSECTION 4.3. BGP 7 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 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 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 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 devel￾opment 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” 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 topology, using a routing protocol called EGP. (While the modern use of the term EGP