Motivation, Analysis, and Architecture for IPv4aaS

Motivation, Analysis, and Architecture for IPv4aaS - See more at: https://www.nanog.org/meetings/abstract?id=2572#sthash.nEGQdBEn.dpuf 

In this talk, we share our work in creating an “IPv4 as a service” network overlay. We begin by suggesting there is value in building network infrastructure which is “lean” and "IPv6 focused". There is likely value in focusing on a lean FIB infrastructure and IPv6 focused functionality in our next-generation routing platforms. We performed traffic analysis on how IPv4 is being used in our network today. We found that 90% of the traffic in our fully routed backbone is done by %0.005 of the routes. 99% of the traffic is performed by 4.5% of the prefixes. This data suggests we can incrementally deploy an IPv4aaS solution. Our goal is to build an IPv4aaS using cloud infrastructure based on open source and home grown software. We then present an IPv4aaS built on top of LISP. While we use LISP encapsulation, we have decided not to use the LISP DDT “routing” mechanism. Our IPv4aaS overlay routing architecture must associate IPv4 prefixes with IPv6 next-hops. This isn’t supported with “classic” BGP today. To solve this, we augmented JSON BGP IPv4 prefix updates with additional JSON information, namely an IPv6 next-hop. Effectively, we created a BGP IPv4 update with an IPv6 next-hop value. These messages are HTTP PUT to a route reflector / controller device, which processes the updates and applies associated business rules. These messages are then HTTP PUT to the overlay ingress (iTR) which announce a “default” to the underlay network. We then suggest the concepts in this presentation are an extension to the concepts we've made at the previous two June NANOG meetings.

 Discussion of IPv4 overlay on top of IPv6 over time. So wants to start thinking about how that should look like before it happens. Assumption is that the world moves to v6 and optimizes for v6 and then keeps v4 running somehow.

Concepts: Want to have a "lean core" to reduce costs for hardware, mgmt, etc. That means v6-only core as the endgame, so need to think about getting there over time.

575K prefixes in current FIB. Based on studies, 72 percent of prefixes being advertised are not being used. Only about 160K prefixes have traffic. 415K prefixes have no measurable traffic!

Comcast analysis: to carry 90 percent of v4 load need 3,156 prefixes. About 2,300 Comcast, 900 Internet.

Thinking about building overlay/underlay, looks like don't need that many prefixes for the v4 overlay.

99 percent point is 25,893 prefixes (from comcast view of world) - about 6K are comcast prefixes.
So 99 percent of Internet is carried on about 20K prefixes. Very interesting....

Use LISP to virtualize v4 delivery in the cloud. IPv4aaS as overlay in VMs on cloud infrastructure. LISP ETRs and ITRs close to customer ingress/egress. Overlay would be primarily outbound service.

Peering provider can identify which prefixes with significant load and forward via main hardware path. The rest are punted to LISP overlay. Heavy hitter prefixes routed on underlay. The rest carried over overlay.

"openstack isn't quite ready, still too data-center-centric and needs more work to get isolated from DC problem space and become more general for using in this model of overlay/underlay.

Control plane evolution to JSON and HTTP - (NANOG 2013 New Orleans - Applying Web principles to the network)

Open router platforms: (NANOG 2014 Bellevue - open router platforms)
Randy Bush: ask vendors for reduction of prefixes that is possible by de-duplicating information