IEEE CCW 08 New Network Architectures: Why Bother? Paul Francis Cornell

Preview:

Citation preview

IEEE CCW ‘08

New Network Architectures:Why Bother?

Paul FrancisCornell

What is a “home run” in systems research?

Huge impact on industry

Intellectually compelling idea

Something that industry wouldn’t have done on its own

Impact

Intellectual

Not done byIndustry

A home run

What is a “home run” in systems research?

Huge impact on industry

Intellectually compelling idea

Something that industry wouldn’t have done on its own

As industry matures, these get increasingly difficult

Impact

Intellectual

Not done byIndustry

This is new architecture(“clean slate”) research

“Dirty slate” research....

Maybe. But only with incrementally deployable ideas.

Is it possible to hit a home run in networking research these days?

Finding a fun project that industry wants to deploy is itself an intellectual challenge....

One approach is to become a vendor

The challenge of impact in network research:

Need buy-in from providers, vendors, and standards

Do a startup

But this is not always possibleInter-domain routing, for instance

One Bottleneck at a Time

Rather, solve the current most serious problem, move on

Our approach to inter-domain routing research

Don’t solve every problem at once

Virtual Aggregation (ViAggre)

In fact, ViAggre requires no changes to router software!

ISPs sometimes have to replace hardware because of FIB growth

Shrinks the BGP FIB (by easily 10x), but leaves the RIB intact

Intact RIB means no real change to how routing is done

Today: All router FIBs have routes to all destinations

Dest Next Hop20.5/16 1.1.1.136.3/16 2.1.1.1. . . .

Virtual Aggregation: FIBs have routes to only part of the address space

Virtual Prefixes

Dest Next Hop20.5/16 1.1.1.1. . . .

Dest Next Hop188.3/16 2.1.1.1. . . .

Paths through the ISP have two components:

1: Route to a nearby Aggregation Point

2: Tunnel to the neighbor router

1: Routing to a nearby Aggregation Point

Configure Aggregation Point with static route for the Virtual Prefix

Virtual Prefix is advertised into BGP

2: Tunnel packet to neighbor router (MPLS)

Static routes for all neighbors are imported into OSPF

MPLS LDP creates tunnels to every neighbor router

Turns out, providers are nervous about doing anything without vendor blessing

We thought we could bypass vendors and standards

Providers could deploy this on their own

Fortunately, a vendor (Huawei) became interested in this

Huawei is implementing it

Standardizing ViAggre in IETF (IDR)

Going well, because no changes to BGP

With RFC in hand, can try to get providers to convince other vendors to implement

I suspect that it is not RIB size, but rather BGP update processing cost

Assuming FIB is “solved”, what’s the next bottleneck?

We are starting some router measurements to find out

Can we reduce the cost of updates while running BGP more-or-less as is?

Mapped-BGP

Filtering, best-path selection, load-balance, aggregation, route policies

Expense of route processing are all the policies

Our goal is to get rid of the policies for most prefixes

Rather than distribute routes to all prefixes, distribute routes to tunnel endpoints, and distribute “maps” that bind prefixes to tunnel endpoints

Make the maps policy-free

Exploit tunnels to improve inter-AS load balance and increase aggregation opportunities