Internet Routing (COS 598A) Today: Non-Convergence: Policy Conflicts

1. Internet Routing (COS 598A)Today: Non-Convergence: Policy Conflicts Jennifer Rexford http://www.cs.princeton.edu/~jrex/teaching/spring2005 Tuesdays/Thursdays 11:00am-12:20pm

2. Outline • Stable Paths Problem • The problem BGP is solving • Abstract model for BGP • Translating reality into SPP • Conflicting routing policies • Examples of policy conflicts • Difficulty of identifying conflicts • Guaranteeing convergence • Guidelines based on business relationships • Provable convergence without global control • Recent work and a project idea

3. What Problem Does a Routing Protocol Solve? • Most do shortest-path routing • Shortest hop count • Distance vector routing (e.g., RIP) • Shortest path as sum of link weights • Link-state routing (e.g., OSPF and IS-IS) • Policy makes BGP is more complicated • An AS might not tell a neighbor about a path • E.g., Sprint can’t reach UUNET through AT&T • An AS might prefer one path over a shorter one • E.g., ISP prefers to send traffic through a customer What is a good model for BGP?

4. Could Use A Simulation Model • Simulate the message passing • Advertisements and withdrawals • Message format • Timers • Simulate the routing policy on each session • Filter certain route advertisements • Manipulate the attributes of others • Simulate the decision process • Each router applying all the steps per prefix Feasible, but tedious and ill-suited for formal arguments

5. 2 1 0 2 0 5 2 1 0 4 2 0 4 3 0 5 0 3 4 2 1 3 0 1 3 0 1 0 Stable Paths Problem (SPP) Instance • Node • BGP-speaking router • Node 0 is destination • Edge • BGP adjacency • Permitted paths • Set of routes to 0 at each node • Ranking of the paths 2 1 most preferred … least preferred

6. 5 2 1 0 5 0 3 4 2 1 A Solution to a Stable Paths Problem • Solution • Path assignment per node • Can be the “null” path • If node u has path uwP • {u,w} is an edge in the graph • Node w is assigned path wP • Each node is assigned • The highest ranked path consistent with the assignment of its neighbors 2 2 1 0 2 0 4 2 0 4 3 0 3 0 1 3 0 1 0 1 A solution need not represent a shortest path tree, or a spanning tree.

7. 5 0 2 Translating a Real Configuration into SPP • Permitted paths at a node • Composition of export policies at other nodes • Ranking of paths at a node • Import policies at the node • Rank in terms of BGP decision process (i.e., local preference, AS path length, origin type, MED, …) 2 1 0 2 0 Node 2 exports “2 1 0” but not “2 0” Node 0 exports route to node 2 5 2 1 0 Node 1 exports “1 0” to node 2

8. 1 2 0 1 0 1 2 0 1 0 1 1 1 0 0 0 2 2 2 2 1 0 2 0 2 1 0 2 0 First solution Second solution An SPP May Have Multiple Solutions 1 2 0 1 0 2 1 0 2 0

9. 1 An SPP May Have No Solution 2 1 0 2 0 2 4 0 3 2 0 3 0 1 3 0 1 0 3 3

10. Stable System Unstable After Failure 2 1 0 2 0 Becomes a BAD GADGET if link (4, 0) goes down. 2 4 0 4 2 0 4 3 0 BGP is not robust : it is not guaranteed to recover from network failures. 4 0 3 1 3 4 2 0 3 0 1 3 0 1 0

11. Strawman Solution Doesn’t Work • Create a global Internet routing registry • Store the AS-level graph and all routing policies • Store all routing policies • But, ASes may be unwilling to divulge • Check for conflicting policies • Analyze the global system and identify conflicts • Contact the affected ASes to resolve them • But, checking is an NP-complete problem • … and, a safe system may be unsafe after failure Goal: sufficient condition for convergence with local control

12. Guaranteeing Convergence

13. Think Globally, Act Locally • Key features of a good solution • Flexibility: allow diverse local policies for each AS • Privacy: do not force ASes to divulge their policies • Backwards-compatibility: no changes to BGP • Guarantees: convergence even if system changes • Restrictions based on AS relationships • Path selection rules: which route you prefer • Export policies: who you tell about your route • AS graph structure: who is connected to who

14. advertisements traffic Customer-Provider Relationship • Customer pays provider for Internet access • Provider exports customer’s routes to everybody • Customer exports only to downstream customers Traffic to the customer Traffic from the customer d provider provider customer d customer

15. advertisements traffic Peer-Peer Relationship • Peers exchange traffic between customers • AS exports only customer routes to a peer • AS exports a peer’s routes only to its customers Traffic to/from the peer and its customers peer peer d

16. Hierarchical AS Relationships • Provider-customer graph is directed & acyclic • If u is a customer of v and v is a customer of w • … then w is not a customer of u w v u

17. Local Path Selection Rules • Classify routes based on next-hop AS • Customer routes, peer routes, and provider routes • Rank routes based on classification • Prefer customer routes over peer/provider routes • Allow any ranking of routes within a class • E.g., rank one customer route higher than another • Gives network operators the flexibility they need • Consistent with traffic engineering practices • Customers pay for service, and providers are paid • Peer relationship based on balanced traffic load

18. Two Interpretations • System is stable because ASes act like this • High-level argument • Export and topology assumptions are reasonable • Path selection rule matches with financial incentives • Empirical results • BGP routes for popular destinations stable for ~10 days • Most instability from a few flapping destinations • ASes should follow rules for system stability • Encourage operators to obey these guidelines • … and provide ways to verify the configuration • Need to consider more complex relationships

19. Playing One Condition Off Against Another • All three conditions are important • Path ranking, export policy, and graph structure • Allowing more flexibility in ranking routes • Allow same preference for peer and customer routes • Never choose a peer route over a shorter customer route • … at the expense of stricter AS graph assumptions • Hierarchical provider-customer relationship (as before) • No private peering with (direct or indirect) providers Peer-peer

20. Extension to Backup Relationships • Backups: liberal export and ranking policies • The motivation is increased reliability • …but ironically it may cause routing instability! Backup Provider Peer-Peer Backup [RFC 1998] provider primary provider backup path failure backup path backup provider failure peer

21. Backup Path Needs Global Significance • Peer-backup relationship between 0 and 1 • Adds backup paths (2,1,0), (3,1,0), … • When link {2,0} fails… • Node 2 prefers (2,3,1,0) through a peer over the backup path (2,1,0) • Leads to the “bad gadget” example 2 4 3 0 1

22. Backup Paths: Keeping Count of Backup Edges • Solution • Prefer routes with fewest backup links • Then, break ties by preferring customer routes • Mechanism • Tag BGP route advertisement with a counter • Increment the count as you cross a backup edge No backup 2 0 2 1 0 2 3 1 0 2 4 1 0 2 4 3 One backup customer One backup peer 0 1

23. Recent Work

24. Recent Work: Relaxing Export Rules • Goal: no restrictions on export and topology • Allow an AS to decide whether to export • Do not require hierarchical relationships • Question • How much do you have to restrict path ranking to have a guarantee that the system is safe? • Answer • Limited to shortest-path routing • Implications • Trade-off in safety, autonomy, & expressiveness Recent work by Nick Feamster and Ramesh Johari

25. Recent Work: MED Oscillation (RFC 3345) • MED comparison when next-hop AS is same • No total ordering at the leftmost router • B > A: preferring smaller router-id • C > B: preferring smaller MED attribute • A > C: preferring eBGP-learned over iBGP AS 2 AS 1 B: Id=1, MED=20 C: MED=10 A: Id=2 iBGP

26. Project Idea: Stable Paths Problem and Root-Cause Analysis

27. Project Idea: Root-Cause Analysis • Root-cause analysis • Identify location and cause of routing changes • Inference from BGP protocol messages • Active area of research • Several proposed algorithms • Limited accuracy in making inferences • Research question • Is the problem just very hard? • Does the data not reveal enough information? • Project idea: study using SPP

28. Project Idea, Continued • Model root-cause analysis • Start with an SPP instance • Fail a link (or a node) • See what path changes would occur • What events might cause these changes? 1 2 0 1 0 2 3 4 0 2 0 3 4 0 3 2 0 1 3 2 4 0 0 4

29. Questions • Can you infer cause and location • If you observe routing changes at all nodes • If you observe only some of the nodes • What if you make some assumptions • E.g., policies based on business relationships • Where would you place monitors? • Best locations to place n monitors • Minimum number of monitors you need • What changes would you make to the routing protocol to make diagnosis easier?

30. Next Time: Hot-Potato Routing • Two papers • “Dynamics of Hot-Potato Routing in IP Networks” • “TIE Breaking: Tunable Interdomain Egress Selection” • NANOG video • Covering material in the first paper • In honor of spring break • No written reviews • Talk with me about your course project • ... by Thursday March 24 • Final written report due Tuesday May 10