Métaroutage

1. Métaroutage timothy.griffin@cl.cam.ac.uk L’école d’été RÉSCOM 2007 Calcotoggio, Corse, 21 Juin

2. Tutorial Outline • Motivation : shortage of routing protocols • Review of Metarouting paper [GS_MR] • Open problems • Expressive power of “abstract metalanguage” • User-oriented languages • Compilation • Forwarding • Other applications? MANET routing.

3. 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

4. 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

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

6. Cable & Wireless CAIS Telefonica AT&T B =Intel Berkeley Above Net A B = HP Palo Alto 201 ms 4 ms C A 257 ms The Joy of Interdomain Routing RBNet C B A C =Moscow State U

7. http://www.larrysface.com/

8. The Problem • Small number of routing protocols • Design, implementation, deployment, standardization  long, slow process • BGP is being pressed into service as an IGP • No convergence guarantees • BGP Wedgies (RFC 4264) • Endless stream of BGP extensions • Cost Communities • Use of BGP for VPN routing (RFC 2547)

9. The half wedgie What is a BGP Wedgie? [RFC 4264] • BGP policies make sense locally • Interaction of local policies allows multiple stable routings • Some routings are consistent with intended policies, and some are not • If an unintended routing is installed (BGP is “wedged”), then manual intervention is needed to change to an intended routing • When an unintended routing is installed, no single group of network operators has enough knowledge to debug the problem The full wedgie

10. Half Wedgie Example • AS 1 implements backup link by sending AS 2 a “depref me” community. • AS 2 implements this community so that the resulting local pref is below that of routes from it’s upstream provider (AS 3 routes) peer peer AS 3 AS 4 provider provider customer AS 2 primary link provider backup link customer customer AS 1

11. AS 3 AS 4 AS 2 AS 1 And the Routings are… AS 3 AS 4 AS 2 AS 1 Intended Routing Unintended Routing Note: this would be the ONLY routing if AS2 translated its “depref me” community to a “depref me” community of AS 3 Note: This is easy to reach from the intended routing just by “bouncing” the BGP session on the primary link.

12. AS 3 AS 4 AS 2 AS 1 Recovery • Requires manual intervention • Can be done in AS 1 or AS 2 AS 3 AS 4 AS 3 AS 4 AS 2 AS 2 AS 1 AS 1 Bring down AS 1-2 session Bring it back up!

13. 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 • Lab demonstrations of BGP configs never converging • Complex policies (weights, communities setting preferences, and so on) increase chances of routing anomalies. • … yet this is the current trend!

14. Load Balancing Example peer peer AS 3 AS 4 Simple session reset my not work!! provider provider customer customer AS 2 AS 5 primary link for prefix P2 backup link for prefix P1 primary link for prefix P1 backup link for prefix P2 AS 1

15. 3 4 BOTH P1 & P2 wedged 2 5 3 4 1 3 3 4 4 3 4 3 4 2 5 2 2 5 5 2 5 2 5 1 1 1 1 1 1—2 up 1—5 up Reset 1—2 Reset 1—5 1—2 & 1—5 down 1—2 & 1—5 down 3 4 3 4 2 5 2 5 1 1 Can’t un-wedge with session resets! all up all up Note that when bringing all up we could actually land the system in any one of the 4 stable states --- depends on message order…. P2 wedged P1 wedged INTENDED 1—2 down 1—5 down

16. Temporarily filter P2 from 1—5 session Temporarily filter P1 from 1—2 session 3 4 3 4 3 4 2 5 2 5 2 5 1 1 1 1—5 up 1—2 up 3 4 3 4 2 5 2 5 1 1 Recovery P2 wedged P1 wedged INTENDED 1—2 down 1—5 down Who among us could figure this one out? When 1—2 is in New York and 1—5 is in Tokyo?

17. backup links Full Wedgie Example • AS 1 implements backup links by sending AS 2 and AS 5 a “depref me” communities. • AS 2 implements its community so that the resulting local pref is below that of its upstream providers and it’s peers (AS 3 and AS 5 routes) • AS 5 implements its community so that the resulting local pref is below its peers (AS 2) but above that of its providers (AS 3) peer peer AS 3 AS 4 provider provider customer customer peer peer AS 5 AS 2 provider primary link customer customer AS 1

18. And the Routings are… AS 3 AS 4 AS 3 AS 4 AS 5 AS 5 AS 2 AS 2 AS 1 AS 1 Intended Routing Unintended Routing

19. AS 3 AS 4 AS 5 AS 2 AS 1 Resetting 1—2 does not help!! AS 3 AS 4 AS 5 AS 2 AS 1 Bring down AS 1-2 session Bring up AS 1-2 session

20. AS 3 AS 4 AS 5 AS 2 AS 1 Recovery AS 3 AS 4 AS 3 AS 4 AS 5 AS 5 AS 2 AS 2 AS 1 AS 1 Bring down AS 1-2 session AND AS 1-5 session Bring up AS 1-2 session AND AS 1-5 session A lot of “non-local” knowledge is required to arrive at this recovery strategy! Try to convince AS 5 and AS 1 that their session has be reset (or filtered) even though it is not associated with an active route!

21. NA AP EMEA LA AU++ That Can’t happen in MY network!! An “normal” global global backbone (ISP or Corporate Intranet) implemented with 5 regional ASes

22. NA AP LA EMEA AU The Full Wedgie Example, in a new Guise Intended Routing for some prefixes in AU, implemented with communities. DOES THIS LOOK FAMILIAR?? Message: Same problems can arise with “traffic engineering” across regional networks.

23. The Problem • Small number of routing protocols • Design, implementation, deployment, standardization  long, slow process • BGP is being pressed into service as an IGP • No convergence guarantees • BGP Wedgies (RFC 4264) • Endless stream of BGP extensions • Cost Communities • Use of BGP for VPN routing (RFC 2547)

24. Is there a Betterer way?

25. Metarouting= Let Operators Decide • We don't know how to define generic IGPs for every network ----let the operators decide. • We don't know how to define IBGPs for every network ---let the operators decide. • We don't know how to fix EBGP or how to evolve it for changing requirements ---let the operators decide. • Operators can decide, if only they are given the right tools.

26. How routes are described How routes are compared How policy is described How policy is applied Central Dogma Routing Protocol = Routing language+Routing Algorithms+Proof • How routing solutions are computed • How adjacencies are established and maintained • … • Does the protocol converge? • Is resulting forwarding loop-free? • …

27. Basic Thesis Routing languages should not be hard-coded into protocols specifications and implementations. • Allow the operator community to define routing languages and routing protocols that fit the needs of their networks (IGPs, IBGPs). • Allow the operator community to standardize and evolve interdomain routing languages.

28. How? Standardize (IETF) and implement a generic (routing language Independent) set of algorithms such as BGP-like hard state path vector, RIP-like soft-state path-vector, OSPF-like link state flooding and generalized Dijkstra. Define a metalanguage for the specification of routing languages. This language must be carefully constructed to be highly expressiveness while at the same time allowing the automatic derivation of properties required for proofs. Standardize the metalanguage (IETF?) Routing Protocol = Routing Language + Routing Algorithms + Proof Proofs are automated: simply match the derived properties of the metalanguage specification with the required properties of each algorithm used. LIBERATE NETWORK OPERATORS FROM THE IETF

29. Routing Algebras [JS_Alg] m m + n n Generalize Shortest Paths

30. Routing Algebras An ordered set of signatures is a set of policy labels Is the policy application function Note : the notations in this tutorial differ a bit from those in [JS_Alg, GS_MR].

31. Important Properties Non-decreasing (ND) Increasing (IN) Monotonicity (M) (SI) Strict Monotonicity

32. What makes these algorithms work? • Generalized Dijkstra (Think Link State) • Correctness proof uses M, • Loop-freedom for hop-by-hop forwarding uses IN. • Generalized Bellman-Ford (Vectoring) • Convergence proof uses IN, • Loop-freedom for hop-by-hop forwarding uses strict IN

33. An algebra for OSPF? (hand-coded from careful reading of RFC 2328 I’m not sure that it is correct, but that’s not the point….) e (1, e, s) (1, (1, v), s) (1, (2, v), s) (2, e, s) (2, (1, v), s) (2, (2, v), s) (1, l) (1, e , l e) (1, e , l s) (1, (1, v), l s) (1, (2, v), l s) (2, e , l s) (2, (1, v), l s) (2, (2, v), l s) (1, (1, v), l e) (1, (1, v), l) f f f f f f (1, (2, v), l) (1, (2, v), l e) f f f f f f (2, l) f (2, e , l e) (2, e , l s) (2, (1, v), l s) (2, (2, v), l s) f f (2, (1, v), l) f f f f f f (2, (1, v), l e) (2, (2, v), l e) (2, (2, v), l) f f f f f f <1, …> = intra-area route <2, …> = inter-area route <{1,2}, l> = “normal” route <{1,2}, <1, v>, l> = type I external <{1,2}, <2, v>, l> = type II external

34. Routing Algebras are a good start, but… • The algebraic framework does not, by itself, provide a way of constructing new and complex algebras. • Algebra definition is hard… • Proofs are tedious… • Modifications to an algebra’s definitions are difficult to manage…

35. Routing Algebra Meta-Language ::= • “Abstract syntax” for generating new Algebras • Key innovation: automatically derive properties (ND, IN, …) of the algebra represented by an expression from properties of base algebras and preservation properties of operators • Other goals • Simplicity • Expressiveness A B (base algebras) | Op(A) (unary operator) | A Op A (binary operators)

36. Some Examples: Lexicographic Product

37. Property Preservation with Lex Product ND ND ND EQ,SM M M IN IN EQ,SM SM SM ND IN IN EQ EQ EQ A design pattern: IN All at least ND IN Don’t care!

38. Disjoint Label Union Same order Structure

39. Disjoint Union : Property Preservation ND ND ND M M M IN ND ND SI M M ND IN ND M SM M IN IN IN SM SM SM

40. Local Preference, Origin Preference (NOT NICE!) (Always ND, M)

41. BGP-like Partition internal external internal

42. Scoped Product

43. Scoped Product : Property Preservation IN ND ND IN IN IN These rules can be automatically derived

44. Area Product

45. Area Product : Property Preservation ND ND ND IN IN IN These rules can be automatically derived

46. Current work and Open Problems • Current prototype implemented in Ocaml • Compilation : generating C code implementation • using Quagga and XORP code base • Modeling • Forwarding, tunneling • Administrative distance • Protocol interaction • Protocol migration • Design and implementation of routing metalanguage • Relational algebra vs. SQL • Novel IGP design and testing • What is the right mathematical setting for the metalanguage?

47. Quadrants Model of Algebraic Routing alexander.gurney@cl.cam.ac.uk timothy.griffin@cl.cam.ac.uk WORK IN PROGRESS

48. Languages for defining Languages A space of Routing Languages Routing Languages that can be expressed in a fixed meta-language Question: What is a good formalism for the space of routing languages?

49. Mind the Gap Metarouting. tgg & Sobrinho (2005) Sobrinho’s Routing Algebra (2003) Sobrinho’s QoS Algebra (2002) Semiring routing (1970’s …) BGP analysis (mid 1990’s  present) Shortest paths (1950’s) Maze Solving (1800’s)

50. 3 Basic Structures Blue = optional properties Antisymmetric Total Bounded … commutative selective has identity element has absorbtive element … has identity closed under composition idempotent …