The Case for Separating Routing from Routers
Key idea
Separating IP routers and the control plane (routing control platform, aka RCP) to deal with increasing complexity of the routing system
Mechanism
RCP use a new way of selecting routes for each router
RCP could exchange routes using an inter-domain routing protocol other than BGP
Benefits
avoid many internal BGP-related complications (e.g. forwarding loops, signaling partitions)
facilitate traffic engineering diagnosis, troubleshooting
rapid development of features and modifications
enforceable consistency of routes
verifiable correctness properties
reserve autonomy of each AS for selecting paths and applying policies
Background
AS uses
external BGP (eBGP) to exchange reachability information with neighboring domains
internal BGP (iBGP) to distribute routes inside the AS
iBGP propagates eBGP-learned routes throughout an AS
Also IGP: computes paths between routers in an AS
Router combines the best BGP routes with info about internal network topology from IGP to construct a forwarding table that maps destination prefixes to outgoing links
preferring routes with highest local preference, smallest AS path length, lowest origin type, and smallest MED, the decision process favors eBGP-learned routes over iBGP-learned routes
If multiple equally-good routes remain, the router favors the BGP route learned from the nearest border router — the egress point with the smallest IGP path cost — following the common practice of “hot-potato” routing.
Route reflector: forwards routes learned from one route-reflector client to another
Routing policy
import policy: filters unwanted routes and manipulates attributes of the remaining routes
export policy: after selecting the best route, the router applies an export policy to manipulate the attributes and decide whether to propagate the route to a neighbor
Routing Architecture
Three principles
(3.1) The routing architecture must base its routing assignments on a consistent view of routing state.
(3.2) The interfaces between the routing protocols must minimize unexpected or unwanted interactions.
(3.3) The inter-domain routing mechanisms must directly support flexible, expressive policies.
(3.1) Compute routes using consistent state
How the architecture back then violate the principles?
Decomposing routing config state across routers --> complicates policy expression
Problem: implement a new policy requires modification of multiple routers
Sol: a network-wise configuration management entity
Distributed path selection --> routing decisions at one router depend on config of the other routers
Problem: omit a single iBGP session in a full-mesh config could leave a router with no route for certain destinations; also make predicting the effects of config changes difficult
Sol: an entity that performs path assignment on behalf of all routers
Each router unaware of states of other routers --> incorrect or suboptimal routing
Problem: router has iGBP sessions to multiple route reflectors to improve reliability. But when a route reflector fails --> protocol oscillation and forwarding loops can arise if the second route reflector has different view of the best routes.
Sol: an entity that performs route computation using a consistent view of available routes and network topology can be replicated using standard distributed system algorithms
(3.2) Control routing protocol interaction
How the module in today's inter-domain routing system interact in undesirable ways
Hard-wired interactions between eBGP and the IGP --> constrain an operator's control over path selection
Problem: IGP changes lead to best BGP route changes, causing abrupt, unwanted traffic shifts; redirect traffic from one egress link to another requires complex manipulation of BGP import policies
Sol: directly assign new routes to some routers without changing BGP routing policies
Inconsistencies between iBGP and IGP --> forwarding loops and route oscillation
Problem: a route reflector and its clients may have different IGP path costs to the egress routers, leading to different BGP routing decisions --> protocol oscillations or persistent forwarding loops, complicating debugging
Sol: the routing architecture could use the available knowledge to ex- plicitly enforce consistency in router-level forwarding paths
Interactions between overlay networks and the underlying network --> degrade performance
Problem: they lack complete information about routing and traffic-engineering optimizations, these overlays sometimes increase congestion and decrease the effectiveness of traffic engineering in the underlay network
Sol: With more direct control, overlays could operate more efficiently; With more information about routing dynamics, overlays could preemptively avoid some outages
(3.3) Support flexible, expressive policies
BGP’s mechanisms --> preclude the expression of certain policies and make others difficult to express
Problem: moving traffic from one-inter-AS link to another requires 1) identify subset of prefixes 2) determining how to express that subset 3) modify the import policies 4) observing result traffic flow and iterate
Sol: should allow an operator to move traffic by explicitly assigning paths
BGP’s mechanisms --> impede multiple ASes from cooperating in selecting routes that satisfy their goals
Problem: one AS want to advertise a backup route to its neighbor, These two ASes must first negotiate a backup “signal” out of band. The AS advertising the route must then modify its export policies to attach this signal to the backup route, and the neighbor must modify the import policies on its routers to lower the “local preference” value for routes with this community
Sol: inter-domain routing should support route negotiation directly
Last updated
