1 / 40

An open problem in Internet Routing --- Policy Language Design for BGP

An open problem in Internet Routing --- Policy Language Design for BGP. Timothy G. Griffin Intel Research, Cambridge UK tim.griffin@intel.com. Nov 3, 2003. Architecture of Dynamic Routing. IGP. EGP (= BGP). AS 1. IGP. IGP = Interior Gateway Protocol.

lee-drake
Download Presentation

An open problem in Internet Routing --- Policy Language Design for BGP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An open problem in Internet Routing --- Policy Language Design for BGP Timothy G. Griffin Intel Research, Cambridge UK tim.griffin@intel.com Nov 3, 2003

  2. Architecture of Dynamic Routing IGP EGP (= BGP) AS 1 IGP IGP = Interior Gateway Protocol Metric based: OSPF, IS-IS, RIP, EIGRP (cisco) AS 2 EGP = Exterior Gateway Protocol Policy based: BGP The Routing Domain of BGP is the entire Internet

  3. Topology information is flooded within the routing domain Best end-to-end paths are computed locally at each router. Best end-to-end paths determine next-hops. Based on minimizing some notion of distance Works only if policy is shared and uniform Examples: OSPF, IS-IS Each router knows little about network topology Only best next-hops are chosen by each router for each destination network. Best end-to-end paths result from composition of all next-hop choices Does not require any notion of distance Does not require uniform policies at all routers Examples: RIP, BGP Technology of Distributed Routing Link State Vectoring

  4. The Gang of Four Link State Vectoring OSPF RIP IGP IS-IS BGP EGP

  5. Partial View of www.cl.cam.ac.uk (128.232.0.20) Neighborhood AS 20757 Hanse AS 5089 NTL Group AS 3356 Level 3 AS 3257 Tiscali AS 6461 AboveNet AS 1239 Sprint AS 702 UUNET AS 13127 Versatel AS 4637 REACH AS 20965 GEANT AS 786 ja.net (UKERNA) AS 5459 LINX AS 1213 HEAnet (Irish academic and research) Originates > 180 prefixes, Including 128.232.0.0/16 AS 4373 Online Computer Library Center AS 7 UK Defense Research Agency

  6. How Many ASNs are there today? 16,046 Thanks to Geoff Huston. http://bgp.potaroo.net on November 3, 2003

  7. Four Types of BGP Messages • Open : Establish a peering session. • Keep Alive : Handshake at regular intervals. • Notification : Shuts down a peering session. • Update : Announcing new routes or withdrawing previously announced routes. announcement = prefix + attributes values

  8. BGP Attributes Value Code Reference ----- --------------------------------- --------- 1 ORIGIN [RFC1771] 2 AS_PATH [RFC1771] 3 NEXT_HOP [RFC1771] 4 MULTI_EXIT_DISC [RFC1771] 5 LOCAL_PREF [RFC1771] 6 ATOMIC_AGGREGATE [RFC1771] 7 AGGREGATOR [RFC1771] 8 COMMUNITY [RFC1997] 9 ORIGINATOR_ID [RFC2796] 10 CLUSTER_LIST [RFC2796] 11 DPA [Chen] 12 ADVERTISER [RFC1863] 13 RCID_PATH / CLUSTER_ID [RFC1863] 14 MP_REACH_NLRI [RFC2283] 15 MP_UNREACH_NLRI [RFC2283] 16 EXTENDED COMMUNITIES [Rosen] ... 255 reserved for development Most important attributes Not all attributes need to be present in every announcement From IANA: http://www.iana.org/assignments/bgp-parameters

  9. BGP Route Processing Open ended programming. Constrained only by vendor configuration language Apply Policy = filter routes & tweak attributes Apply Policy = filter routes & tweak attributes Receive BGP Updates Based on Attribute Values Best Routes Transmit BGP Updates Apply Import Policies Best Route Selection Best Route Table Apply Export Policies Install forwarding Entries for best Routes. IP Forwarding Table

  10. Route Selection Summary Highest Local Preference Enforce relationships Shortest ASPATH Lowest MED traffic engineering i-BGP < e-BGP Lowest IGP cost to BGP egress Throw up hands and break ties Lowest router ID

  11. ASPATH Attribute AS 1239 Sprint AS 1129 135.207.0.0/16 AS Path = 1755 1239 7018 6341 Global Access AS 1755 135.207.0.0/16 AS Path = 1239 7018 6341 135.207.0.0/16 AS Path = 1129 1755 1239 7018 6341 Ebone AS 12654 RIPE NCC RIS project 135.207.0.0/16 AS Path = 7018 6341 AS7018 135.207.0.0/16 AS Path = 3549 7018 6341 135.207.0.0/16 AS Path = 6341 AT&T AS 3549 AS 6341 135.207.0.0/16 AS Path = 7018 6341 AT&T Research Global Crossing 135.207.0.0/16 Prefix Originated

  12. Shorter Doesn’t Always Mean Shorter Mr. BGP says that path 4 1 is better than path 3 2 1 In fairness: could you do this “right” and still scale? Exporting internal state would dramatically increase global instability and amount of routing state Duh! AS 4 AS 3 AS 2 AS 1

  13. Shedding Inbound Traffic with ASPATH Prepending Prepending will (usually) force inbound traffic from AS 1 to take primary link AS 1 provider 192.0.2.0/24 ASPATH = 2 2 2 192.0.2.0/24 ASPATH = 2 primary backup customer Yes, this is a Glorious Hack … 192.0.2.0/24 AS 2

  14. … But Padding Does Not Always Work AS 1 AS 3 provider provider 192.0.2.0/24 ASPATH = 2 192.0.2.0/24 ASPATH = 2 2 2 2 2 2 2 2 2 2 2 2 2 2 AS 3 will send traffic on “backup” link because it prefers customer routes and local preference is considered before ASPATH length! Padding in this way is often used as a form of load balancing primary backup customer 192.0.2.0/24 AS 2

  15. COMMUNITY Attribute to the Rescue! AS 3: normal customer local pref is 100, peer local pref is 90 AS 1 AS 3 provider provider 192.0.2.0/24 ASPATH = 2 COMMUNITY = 3:70 192.0.2.0/24 ASPATH = 2 primary backup Customer import policy at AS 3: If 3:90 in COMMUNITY then set local preference to 90 If 3:80 in COMMUNITY then set local preference to 80 If 3:70 in COMMUNITY then set local preference to 70 customer 192.0.2.0/24 AS 2

  16. Don’t celebrate just yet… Provider A (Tier 1) Provider B (Tier 1) peering provider/customer provider/customer Provider C (Tier 2) customer Now, customer wants a backup link to C….

  17. Customer installs a “backup link” … Provider A (Tier 1) Provider B (Tier 1) Provider C (Tier 2) primary backup customer sends “lower my preference” Community value customer

  18. Disaster Strikes! Provider A (Tier 1) Provider B (Tier 1) Provider C (Tier 2) primary backup customer customer is happy that backup was installed …

  19. The primary link is repaired, and something odd occurs… Provider A (Tier 1) Provider B (Tier 1) Provider C (Tier 2) primary backup customer YIKES --- routing DOES NOT return to normal!!!

  20. WAIT! It Gets Better… A B B B P C B D P = primary B = backup

  21. OOOOOPS! A B B B P C B No solution = Protocol Divergence D Suppose A, B, C all break ties in the same direction (clockwise or counter-clockwise)

  22. What the heck is going on? • There is no guarantee that a BGP configuration has a unique routing solution. • When multiple solutions exist, the (unpredictable) order of updates will determine which one is wins. • There is no guarantee that a BGP configuration has any solution! • And checking configurations NP-Complete [GW1999] • Complex policies (weights, communities setting preferences, and so on) increase chances of routing anomalies. • … yet this is the current trend!

  23. What Problem is BGP Solving? Underlying problem Distributed means of computing a solution. Shortest Paths RIP, OSPF, IS-IS ???? Stable Paths BGP [GSW1998, GSW2002]

  24. An instance of the Stable Paths Problem (SPP) 2 1 0 2 0 5 2 1 0 4 2 0 4 3 0 1 4 2 0 5 3 3 0 1 3 0 1 0 2 • A graph of nodes and edges, • Node 0, called the origin, • For each non-zero node, a set or permitted paths to the origin. This set always contains the “null path”. • A ranking of permitted paths at each node. Null path is always least preferred. (Not shown in diagram) 1 most preferred … least preferred When modeling BGP : nodes represent BGP speaking routers, and 0 represents a node originating some address block

  25. A Solution to a Stable Paths Problem 5 2 1 0 5 1 0 2 4 3 2 2 1 0 2 0 A solution is an assignment of permitted paths to each node such that 4 2 0 4 3 0 • node u’s assigned path is either the null path or is a path uwP, where wP is assigned to node w and {u,w} is an edge in the graph, • each node is assigned the highest ranked path among those consistent with the paths assigned to its neighbors. 3 0 1 3 0 1 0 1 A Solution need not represent a shortest path tree, or a spanning tree.

  26. An SPP may have multiple solutions 1 1 1 0 0 0 2 2 2 1 2 0 1 0 1 2 0 1 0 1 2 0 1 0 2 1 0 2 0 2 1 0 2 0 2 1 0 2 0 First solution Second solution DISAGREE

  27. BAD GADGET : No Solution 2 1 0 2 0 2 4 0 3 2 0 3 0 1 3 0 1 0 3 3 1 This is an SPP version of the example first presented in Persistent Route Oscillations in Inter-Domain Routing. Kannan Varadhan, Ramesh Govindan, and Deborah Estrin. Computer Networks, Jan. 2000

  28. SURPRISE! 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

  29. PRECARIOUS 4 3 1 0 4 5 3 1 2 0 4 3 1 2 0 1 2 0 1 0 3 1 0 3 1 2 0 1 3 0 5 3 1 0 5 6 3 1 2 0 5 3 1 2 0 6 3 1 0 6 4 3 1 2 0 6 3 1 2 0 2 1 0 2 0 5 4 2 6 As with DISAGREE, this part has two distinct solutions This part has a solution only when node 1 is assigned the direct path (1 0). Has a solution, but path vector may not find it!

  30. A Sufficient Condition for Robustness P Q : transitive closure of (subpath relation on permitted paths union the path ranking relation at each node) This is a sufficient condition for robustness Partially Partially Ordered (PP0): For all paths P and Q, P Q and Q P implies (P = Q or head(P) = head(Q)) PPO iff ranking functions can be rewritten to be strictly increasing along all paths Checking PPO at the “language level” is an NP-Complete problem

  31. Why is BGP not causing more trouble? If the provider/customer digraph is acyclic and every AS obeys the commandments • Thou shall prefer customer routes over all others • Thou shall use provider routes only as a last resort • Thou shall not provide transit between peers or providers then the BGP configuration is robust. [see Gao-Rexford and Gao-Griffin-Rexford]

  32. Hierarchical BGP (HBGP) HBGP +PEER + BU HBGP + BU HBGP +PEER HBGP [GR2000, GGR2001]

  33. Can BGP be fixed? • BGP policy languages have evolved organically • A policy language really should be designed! • But how? Joint work with Aaron Jaggard (UPenn Math) and Vijay Ramachandran (Yale CS) to appear at SIGCOMM 2003

  34. Design Dimensions • Robustness (required!) • Transparency (required!) • Expressive Power • Autonomy (“local wiggle room”) • Local vs. Global Constraints • Policy Opacity Tradeoffs galore

  35. General Autonomy Suppose C and K are any predicates that partition all routes. Then it is possible to write policies, with no inbound filtering, such that for all imported routes, those that satisfy C are ranked below those that satisfy K.

  36. A Partial Ordered for the Design Space ( J , L ) < ( J , L ) 1 1 2 2 Global Constraint Local Constraint if and only if for all S : SPP • J(S)impliesJ(S) • L(S)impliesL(S) 2 1 1 2 2

  37. Robust Designs ( J, L ) is a robust design if (J andL ) impliesPPO Examples: ( True, SP ) 2 ( PPO, True )

  38. Robust Subspace Not tractable Tractable ( PPO, True ) Constraint Simplicity Expressive Power ( True, SP )

  39. Need Global Constraints Theorem: Any robust system supporting both transparency and autonomy must have a non-trivial global constraint Global constraints must be a part of design from the start

  40. Next? • Need techniques for constructing policy languages. • Design of protocols to enforce global constraints. • Can ad-hocery be avoided?

More Related