Putting BGP on the Right Path: A Case for Next-Hop Routing

1
Putting BGP on the Right Path A Case for
Next-Hop Routing

• Michael Schapira
• Joint work with Yaping Zhu and Jennifer Rexford
• (Princeton University)

2
Once Upon a Time Internet Inter-Network Routing

• Small network
• Single administrative entity
• NSFNET
• Shortest-path routing
• distance-vector routing
• Then....

3
Interdomain Routing

• Over 35,000 Autonomous Systems (ASes)
• Interdomain routing routing between ASes
• Border Gateway Protocol (BGP)

Sprint
ATT
Comcast
Qwest
4
Todays Path-Based Routing With BGP

• Complex!
• configuration errors, software bugs,
• Bad convergence!
• persistent route oscillations, slow convergence,
  
• Vulnerable to attacks!
• malicious, economically-driven, inadvertent,
• and more, and more, and more
• bad performance, clumsy traffic engineering,

5
How Can We FixInterdomain Routing?

• One approach add mechanisms to an already
  complex protocol
• route flap damping, S-BGP,
• Another approach redesign interdomain routing
  from scratch
• HLP, NIRA, pathlet routing, consensus routing,
• Our approach simplify BGP!

6
Background Todays Path-Based Routing With BGP

• AS is routing policy
• ranking of simple routes from i to each
  destination d
• export policy
• BGP is a path-vector protocol

7
Background Todays Path-Based Routing With BGP
3, Im using 1d
32d gt 31d
1
1, 2, Im available
3
d
2
Dont export 2d to 3
a stable state is reached
8
AS-PATH the Route of All Evil

• AS-PATH list of all ASes on path
• originally meant for loop-detection
• The AS-PATH is to blame!
• error-prone, software bugs
• no/slow convergence
• large attack surface
• bad scalability, clumsy traffic engineering, bad
  performance,

9
Getting Off the AS-PATH

• No way back to shortest-path routing
• Our proposal next-hop routing
• make routing decisions based solely on the next
  hop
• relegate the AS-PATH to its original role

10
Wish List

• Loop freedom
• Fast Convergence
• Security
• Incentive compatibility
• Business policies
• Good performance
• Traffic engineering
• Scalability
• Simplicity

11
Expressiveness vs. Complexity
complexity
too complex
simple
expressiveness
not expressiveenough
sufficientlyexpressive
extremelyexpressive
12
Next-Hop Routing Rules!

• Rule 1 use next-hop rankings

541d gt 53d gt 542d
4 gt 3
1
4
d
5
2
3
13
Next-Hop Routing Rules!

• Rule 1 use next-hop rankings
• Rule 2 prioritize current route
• to minimize path exploration Godfrey-Caesar-Hagen
  -Singer-Shenker

23 Prioritize current route
23 Break ties in favor of lower AS number
2
d
1
3
14
Next-Hop Routing Rules!

• Rule 1 use next-hop rankings
• Rule 2 prioritize current route
• Rule 3 consistently export
• to avoid disconnecting upstream nodes
  Feigenbaum-S-Ramachandran

1 gt 2, Export 32d, but not 31d, to 4
1 gt 2, Export 31dto 4
1
d
3
4
2
15
Next-Hop Routing Rules!

• Rule 1 use next-hop rankings
• Rule 2 prioritize current route
• Rule 3 consistently export
• Defn Node i consistently exports w.r.t. neighbor
  j if there is some route R s.t. each route Q is
  exportable to j iff R i Q.
• Defn Node i consistently exports if it
  consistently exports with respect to each
  neighboring node j.

16
Next-Hop Routing Rules!

• Rule 1 use next-hop rankings
• Rule 2 prioritize current route
• Rule 3 consistently export
• 3 deployment schemes
• Configure todays routers
• Create new router configuration interface
• Build new router software

17
Wish List Revisited

• Loop freedom
• Fast convergence
• Security
• Incentive compatibility
• Business policies
• Good performance
• Traffic engineering
• Scalability
• Simplicity

18
Wish List Revisited

• Loop freedom
• Fast convergence?
• Security
• Incentive compatibility Feigenbaum-S-Ramachandr
  an
• Business policies
• Good performance
• Traffic engineering
• Scalability?
• Simplicity

19
Existence of Stable State

• Existence of stable state not guaranteed even
  with next-hop rankings (Rule 1)
  Feamster-Johari-Balakrishnan
• Thm If the next-hop routing rules hold, then a
  stable state exists in the network.
• What about (fast!) convergence?

20
BGP Oscillations

• BGP not guaranteed to converge even with
  next-hop routing! Griffin-Shepherd-Wilfong

1
2
2 gt d
1 gt d
d
21
The Commercial Internet

• ASes sign long-term contracts.
• Neighboring pairs of ASes have
• a customer-provider relationship
• a peering relationship

peer
providers
peer
customers
22
Gao-Rexford Framework

• 3 simple conditions that are naturally induced by
  the AS-business-hierarchy.
• Topology condition, Preference condition, Export
  condition
• If the Gao-Rexford conditions hold, then BGP is
  guaranteed to converge to a stable state.
  Gao-Rexford
• But, this might require exponentially-many
  forwarding changes! Syed-Rexford

23
Fast BGP Convergence

• Thm In the Gao-Rexford framework, next-hop
  routing convergence to a stable state involves at
  most O(L2) forwarding changes (L links).
• all network topologies
• all timings of AS activations and update message
  arrivals
• all initial routing states
• all initial beliefs
• implications for routing changes and number of
  BGP updates

24
Simulations

• C-BGP simulator. Cyclops AS-level topology, Jan
  1st 2010 (33,976 ASes, 5000 non-stubs)
• Protocols BGP, Prefer Recent Route (PRR),
  next-hop routing
• Metrics forwarding changes, routing
  changes, updates, AS-PATH length
• Events prefix up, link failure, link recovery
• Methodology 500 experiments, 10,000 vantage
  points (all non-stubs, 5000 stubs)

25
Simulation Results( Forwarding Changes)
maximum number of routing changes in next-hop
routing 3
maximum number of forwarding changesin PRR 10
maximum number of BGP forwarding changes gt 20
26
Simulation Results( Routing Changes)
maximum number of routing changes in next-hop
routing lt 20
maximum number of BGP routing changes gt 160
maximum number of routing changesin PRR gt 40
27
Simulation Results( BGP Updates, Non-Stub ASes)
maximum number of updates in next-hop routing lt
300
maximum number of updates in PRR gt 1000
maximum number of BGP updates gt 6000
28
Simulation Results( Routing Changes, The 0.1
Position)
29
Incentive Compatible Routing Configurations
3 gt d gt 1
2
2
d gt 2
3
1
d
Each node is getting its best feasible next-hop
30
Next-Hop Routing isIncentive Compatible

• Thm Feigenbaum-Ramachandran-S In the
  Gao-Rexford framework, next-hop routing is
  incentive compatible.
• (each node is guaranteed its best feasible
  next-hop)

31
Wish List Revisited

• Loop freedom
• Fast convergence
• Security?
• Incentive compatibility
• Business policies
• Good performance?
• Traffic engineering?
• Scalability
• Simplicity

32
Limitations of Next-Hop Routing

• AS-PATH length
• AS-avoiding policies
• AS-name prepending
• AS-PATH-based traffic engineering

33
Security, Performance,Traffic Engineering

• Still open research questions.
• Handled mostly outside the routing protocol.
• We argue that next-hop routing makes things
  mostly better.

34
Performance

• Faster/better convergence than BGP.
• much more scalable.
• Butpotential increase in path lengths.
• b
• loosely correlated with performance ( routers,
  physical distance throughput).
• still, significant increase clearly undesirable!
• Simulation results same path length for 97-99
  of ASes big increase only for 0.1.

35
Security

• Reduces BGPs attack surface (AS-PATH length
  plays no role in routing decisions).
• More resilient to economically-driven attacks
  (incentive compatible).
• More resilient to misconfigurations (in progress)
• But AS-avoiding policies impossible.
• come with no guarantees. e2e?

36
Traffic Engineering

• We discuss how traffic engineering can be done
  without relying on the AS-PATH.
• using different next-hop rankings for different
  (groups of) prefixes
• using the BGP communities attribute

37
Multipath Routing

• Performance, security and traffic engineering can
  greatly benefit from multipath routing.
• multiple working paths
• immediate response to failures
• load balancing among multiple next-hops
• Next-hop routing lowers the barrier for making
  this a reality (work in progress).

38
Multipath Routing

• Exploiting path diversity to
• realize the ASs own objectives
• customize route selection for neighboring ASes
• But... multipath routing is not scalable!
• disseminate and store multiple routes

39
Multipath Routing is Not Scalable!
Im using P1 and P2
1
P1
Im using P1, P2, Q1 and Q2
P2
d
3
4
Q1
Im using Q1 and Q2
2
Q2
40
From AS-PATH to AS-SET

• Next-hop routing is more amenable to multipath
• nodes dont care about entire paths
• other than for loop detection
• Dont announce routes, announce sets!
• set union of ASes on all routes
• BGP route aggregation

41
Neighbor-SpecificNext-Hop Routing

• Customizing route selection for neighbors
• operational motivation Kushman-Kandula-Katabi-Mag
  gs
• economic motivation Wang-S-Rexford

Secure!
R1
C1
?
Short!
R2
C2
z
d
Cheap!
R3
C3
42
Neighbor-SpecificNext-Hop Routing

• Neighbor-Specific BGP Wang-S-Rexford
• implementable using existing tools
• Results for convergence and incentive
  compatibility extend to multipath!

43
Conclusions andFuture Research

• BGP is far too complicated!
• New approach simplify BGP
• without compromising global and local goals!
• Directions for future research
• getting rid of the AS-PATH?
• software / configuration complexity
• more theoretical and experimental work

44
Thank You