Routing Control Platform (English text)

by Sasha Shkrebets — last modified Feb 21, 2023 12:55 PM

Welcome back. In this module we'll talk about a specific example of control and data plan separation called the routing control platform which uses the border gateway protocol as a control channel to control the forwarding decisions of routers inside an autonomous system. We'll start by looking at various problems with BGP, then we'll talk about the details of the routing control platform itself.

Welcome back.

In this module we'll talk about a specific example of

control and data plan separation called the routing control platform

which uses the border gateway protocol as a control channel

to control the forwarding decisions of routers inside an autonomous system.

We'll start by looking at various problems with BGP, then

we'll talk about the details of the routing control platform itself.

Routing control platform is an early

example of control and data point separation.

And the design of the routing

control platform talks about three deployment phases.

Ways that we get from present day BGP to a complete deployment

of the routing control platform or RCP across multiple ASes in the internet.

In this lesson we'll talk about each of these phases as

well as applications that become possible at each stage of deployment.

It probably comes as no surprise that there are many problems with BGP.

It converges slowly and sometimes not at all.

It causes routing loops.

It's misconfigured frequently, and certain network management

tasks like traffic engineering are very difficult.

On the other hand fixing BGP is pretty hard.

Various people have proposed incremental fixes, but some of those

fixes make BGP even more complicated than it already is today.

Other approaches have proposed completely

new architectures and inter-domain routing protocols.

But the deployment of those architectures is almost impossible.

[BLANK_AUDIO]

The fundamental problem with BGP is that the

AS is the logical entity for inter-domain routing.

But the BGP state and logic are decomposed

across routers, so no router has complete BGP state.

And each router makes routing decisions based on a partial

and incomplete view of the state across the entire autonomous system.

BGP also interacts in odd ways with other protocols, most notably

with the IGP, or interior gateway protocol that runs inside an autonomous

system.

By contrast, the routing control platform, or RCP.

Represents an AS as a single logical entity that operates on a complete view

of an autonomous system's routes, and computes

those routes for all routers inside an AS.

The routers themselves no longer have to compute routes.

In a complete deployment of the routing control platform, each AS's RCP.

Communicates routes with RCPSs and other ASes.

But there are incremental deployment phases that allow a single

AS to deploy an RCP and still gain some benefits.

One of the problems with BGP is that configuration state

is decomposed across the routers inside a single autonomous system.

So representing a single coherent network wide policy is quite difficult.

For example consider the implementation of a simple policy

such as don't advertise routes learned from UUNet to Sprint.

In this case, the configuration is decomposed across routers inside the AS.

So the routes themselves must carry state.

In the first portion of the configuration, routers

assign routes from UUNet by tagging the routes.

At the ingress router, C.

In a separate part of the configuration at router A.

In a separate part of the configuration at router A there's

a separate part of the configuration that looks for that particular

tag that was set at C and implements the appropriate filter

to ensure that, that set of routes are not readvertized to Sprint.

This simple policy is decomposed to

cross multiple routers making configuration relatively

difficult.

By contrast the RCP centralizes configuration,

it implements policies for the entire AS.

It knows about sessions to all other ASes.

An infamous policy, in terms of the relationships with those ASes.

This results in much simpler configuration since the

routers themselves don't have to tag routes with state.

Another problem with BGP, is that it interacts

with underlying protocols in strange and unexpected ways.

In this example the router inside the AS, C1

learns a BGP route to some destination D from R1.

And C2 learns a BGP route to the same destination from router RR2.

Because of the way the IGP weights shown with numbers here.

Are configured, C1 will send traffic to D via

the shortest path to RR1 which is via C2.

C2 on the other hand sends packets to D via a path that traverses

both C1 and RR2 because the shortest path to the route it learned via RR2.

Is via C1.

This particular configuration results in a

persistent forwarding group between C1 and C2.

Each of which think they must forward the traffic to D via the other.

The forwarding loop results because no single router

has a complete view of the autonomous system state.

On the other hand.

The RCP can compute routes with complete information.

The RCP learns all externally learned routes and

computes consistent router-level paths across the entire autonomous system.

a result, there's intrinsic loop freedom and convergence.

An RCP, actually doesn't even have to stick to the default decision process.

It could even pin paths for traffic engineering and other purposes.

By setting up custom paths between routers inside the AS and any egress router.

While these features are appealing, of course an important

question remains of how we get from here to there.

In other words how we get from the

situation where all the routers are running iBGP.

With one another making independent decisions to a state where the RCPs are

making the decisions and communicating the BGP

routes with one another across autonomous systems.

There are two issues to consider.

Backwards compatibility and also the incentives for

any single AS to deploy an RCP.

We'll tackle the challenges of deployment by proceeding in three phases.

In the first phase, only a single autonomous system has to deploy an RCP.

Before phase one, we just start with conventional iBGP.

Afterwards, a single RCP learns the best iBGP routes and iGP topology.

Inside a single autonomous system.

In this situation, only a single AS deploys RCP, but

that single AS still gets the benefits of that deployment.

An example application of this limited deployment is controlling path changes.

For example, as we know in BGP.

Routers take routes to the nearest exit, or egress, via the shortest IGP path.

So for example, router C might take a path on the left to router A.

But if that particular length fails, IGP weights will change,

and the shortest path from C to the exit A.

Might increase.

What we don't want to have happen is for

that path from C to leave via different egress.

For example via B.

In standard BGP there's no way to change that because

C will always choose the route to the nearest exit.

But the RCP can pin egress points.

Even as the IGP weights change, ensuring that all of the

routers inside the AS continue to select A as the egress router.

Even as links fail, and internal topology changes.

In the second phase, a single AS can, not only

control routes inside its AS but can implement AS-wide policy.

Based on the eBGP routes it learns from its neighbors.

This requires an additional deployment step where by the RCP must learn

not only all the internal routes, but the eBGP routes from it's neighbors.

So it must have additional eBGP sections configured.

One particular example is efficient aggregation of IP prefixes.

Let's suppose that two egress routers each learn a less specific prefix

and a more specific prefix that's contained inside that larger

prefix.

In this case a router inside the autonomous system.

Might want to aggregate these two prefixes since they overlap but neither of

the routers inside the AS know whether it's safe to do so because

it may be the case that some routers need to forward traffic to

a specific exit point based on the more specific route the egress router learned.

One the other hand, an RCP can determine which routers need more

specific routes, and which routers can get by with less specific routes.

In this case for example the RCP can determine

that it's not safe to aggregate, because a downstream

router will make different decisions about where to forward

traffic to different egresses based on those more specific prefixes.

In the third phase, all ASs have RCPs deployed, and the RCPs communicate

with one another via some inter-AS protocol, which might not even be BGP.

An application of this third phase of deployment is more

flexible routing through better network

management and various protocol improvements.

Once RCPs are talking to one another, it's possible to replace PGP entirely.

So there is a very broad range of

applications that could be deployed in this third phase.

In summary the RCP embodies two principles for inter-domain routing.

It treats an AS as a single logical entity allowing

it to compute consistent routes using a complete AS-wide view.

By acting as a central control point for the AS it can

also control various routing protocol interactions

that were previously difficult to control.

The separation of routing and control allows

for simpler and more expressive routing configuration.

Intrinsic robustness by avoiding forwarding loops and

enabling faster convergence, and the ability to

enable new applications and innovations including the

opportunity for new types of traffic engineering applications.