Preamble: =================== * The two planes of networking * The control plane: Figuring out the basic function of reachability: what path must a packet take to reach a destination? * Data plane: Once reachability has been figured out, how do you actually transmit packets along their paths as quickly as possible? * The control plane kicks in less frequently (only when topology changes) but is more basic and essential: without reachability, performance is meaningless. * The data plane kicks in more frequently (on every packet) but has to do with improving performance. In a way, performance is a second order concern that is crucial once the first order question of reachability has been figured out. * Congestion control and scheduling were examples of the data plane. * The next two lectures are about the control plane. * We'll keep oscillating between these planes in this course. BGP: =================== * The glue that holds the Internet together. * Connects different autonomous systems (ISPs, campuses, etc.) together into one larger Internet. * It's really what makes the Internet a network of networks. * Complicated protocol: many knobs, but no easy way to tune these to achieve desired end goals. * Next class: More expressive routing policies that go beyond BGP. Two forms of routing: =================== * Routing within a domain (campus, etc.): IGP (OSPF, ISIS, etc.): Shortest path routing * Routing across domains (BGP): Policy-constrained routing, no optimality guarantees * We'll focus on BGP here. Inter-AS relationships: =================== * Transit: One larger, regional AS provides service for another smaller, local AS. * Peering: Both ASes carry traffic on behalf of each other. * These relationships are at the heart of the route export and import process. Route export process: =================== * Do advertise a route to a peer's customers to your own customers (that's the whole point of peering) * Don't advertise a route to a peer's customers to your provider or peer (the peering arrangement is for your customers not someone else) * Don't advertise a route to a provider to anyone but your own customers (you don't make money in the process). * It's all about the money. Remember that inter-domain routing is driven by financial incentives above all else. * Aside: Static routes are how individual customers get on the Internet (run route -n on your computer). Route import process: =================== * Every router is essentially free to do whatever it wants. This is the meaning of LOCAL PREF. * Typically, routers act in their own self interest when using LOCAL PREF. * i.e., prefer a customer's routes over a peer's routes over a provider's route in order of priority: (1) make money, (2) pay no money, (3) pay money. BGP in a bit more detail: =================== * BGP itself runs on top of TCP (on port 179): TCP provides reliability so that you don't have to resend periodically. * This seems to violate layering. But it's better to use an existing protocol than invent a new reliable transport at a lower level. * BGP message types: --> 1. OPEN message initiates transfer of current routing tables (after export filtering) --> 2. UPDATE message: Announcements that change existing routes and withdrawals that remove routes. --> 3. KEEPALIVE message: To check that the other end is still alive. * BGP announcement format: IP prefix (destination IP addresses), followed by attributes (Aside: What's a prefix?) eBGP: =================== * Exchange routes between border routers in different ASs. * Border routers are typically directly connected over a physical network or connected over a LAN. * Want to avoid having to find a *route* between two border routers: the recursion must end somewhere :) * Selectively export routes. * Selectively import routes. iBGP: =================== * Goal of iBGP is to collect together all routing information from all the border routers. * Full mesh of iBGP sessions between every eBGP border router and all other routers (iBGP or eBGP). * iBGP is used to disseminate information about external prefixes to all other border and internal routers. * iBGP tells an internal router something like this: to get to this external address go through this border router * How the internal router gets to the border router is the job of the IGP protocol (i.e., OSPF, etc.) * Can use hierarchy (route reflectors) to scale to larger ISPs. The MED attribute: =================== * If an AS has two different entry points (next hops) into the AS for a route that it advertises to another AS. * Then, it uses the MED attribute to say which one it prefers. * Expectation: MED will be honored, but no guarantee, especially in peering. * In customer-provider relationships, money provides an incentive to honor MED. Multi-homing: =================== * An AS wants to connect through two different ASes to have a primary and backup route. * Advertise two routes: pad one route with more ASes to inflate path length and give the impression that it's worse. (BGP has many such hacks.) * But multi-homing is at odds with scalability The Gao-Rexford paper: =================== * Tackles the question of routing stability, i.e., the lack of oscillations. * Routing stability is important because instability can lead to unpredictable network performance and packet reordering, which can affect protocols like TCP. * Stability: The ASes have reached a state from which all subsequent route exports and corresponding route imports keep it in the state. * Safe: The ability to get to a stable state, no matter how you start, what routes you export, and what you import. Some meta comments on Gao-Rexford: =================== * Interesting problem motivation: They could use the Internet Routing Registry to globally coordinate every ISP's routing policies to ensure the system was stable. * However, they observe that operators may be reluctant to share their local policies with others. * Hence, the title: "Stable routing without global coordination." * Unique vantage point at AT&T Labs: a research lab of an ISP. * The authors understood the value of achieving stable routing with minimal intrusiveness to the day-to-day work of network operators. * Quite likely that academic research may have tackled the problem differently. The paper itself: =================== * Formal model of BGP * Defines stability, safety, and models the route import and export at *sufficient* level of detail, without adding too much extraneous detail. * Great example of theory being applied to a real problem and where the theory was almost directly actionable, i.e., wasn't an afterthought or proved in a simplified model. * In general, routing has had more success in achieving correspondence between theory and practice than congestion control. The result itself: ==================== * Simplified version (Guideline A): Prefer a route via customer over a route via a provider or peer. The paper gives a detailed proof and a more detailed guideline (Guideline B). * Pretty intuitive result: Lines up with what an AS would want to do anyway. * Within customers and peers, there is still quite some room for enforcing local policies. * Figure 2 is an example of a network that violates this property and does not converge. AS1 and AS2 are peers and both are providers of AS0. AS1----------AS2 \ / \ / \ / \ / AS0 (d) Both AS1 and AS2 prefer to go through each other rather than AS0 (a customer) when picking a route to d, which is a prefix within AS0. Then the system could oscillate between direct and indirect routes instead of stabilizing. Remember: Routes that lead to loops are implicitly discarded. Conclusions: Several shortcomings with BGP: =================== * Can't authenticate BGP advertisements, which lead to a famous YouTube outage in 2008. * What if you want to split traffic 50-50 across two ASes? (Load balancing / traffic engineering) * What is you want to take different paths for different applications? (Application-specific peering) * What is the convergence time after a failure? Gao-Rexford is silent on how quickly convergence happens. The lecture notes talk about how the convergence time is too slow for mission-critical applications. * These are the focus of the next two papers.