Shrinking and Controlling Routing Table Size

1
Shrinking and Controlling Routing Table Size
Xinyang (Joy) Zhang Paul Francis Jia Wang
Kaoru Yoshida
2
Outline

• We have a trick for making routing tables very
  small
• Global IP, VPNs
• Called CRIO (Core-Router Integrated Overlay)

3
1977

• Folks were looking at the basic trade-off between
  routing table size and path length

4
1977

• Folks were looking at the basic trade-off between
  routing table size and path length

5
1977

• Folks were looking at the basic trade-off between
  routing table size and path length

6
Path-length / Table size trade-off

• A nice trade-off to have
• This trade-off doesnt exist today
• Hierarchical nature of internet forces an
  ISP-centric address assignment model
• Because of multi-homing, sites dont fit neatly
  into a single cloud

7
CRIO has two parts

• Mapping/tunneling part
• Can operate stand-alone
• Virtual prefix part
• Requires mapping/tunneling

8
Mapping/tunneling part

• BGP keeps routes to major POPs only
• 1000 2000 of these
• One prefix per POP
• Separate mapping table binds customer prefixes to
  POPs (ETR address in POP)
• Forwarding is two-step
• Map address to ETR
• Tunnel packet to ETR address
• Not a new idea
• Deerings Map-N-Encap, Kim Claffy et. al.

9
Distributed route computation vs. Data
distribution

• Shifts work from distributed route computation
  problem to data distribution problem
• Easier to debug
• Mapping table is the same everywhere, BGP RIBs
  are not
• Easier to secure
• Secure mapping only, not entire path
• Streamlined BGP can converge faster
• A small number of very stable prefixes
• Operators could crank down the timers

10
Mapping Distribution

• One possibility (in original CRIO)
• Handling by mapping agents (boxes separate from
  routers)
• OSPF-like flooding across agent overlay
• Alternatives
• Handling by routers, using BGP (Atomized Routing)
• Handling by routers, using ICMP-like notification
  (LISP)

11
Mapping Dynamics (using agents)
Agent
mapping ltprefix, ETR1gt invalid (via flooding)
Agent
ISP2
ISP1
prefix withdrawn (via IBGP)
ITR
Selectively install
ETR1
X
CE
ETR2
12
Other mapping characteristics

• Provides a new policy hook
• For multi-homed nodes, mapping can indicate
  access preference
• Tunneling Mechanisms
• One-ended TE accepts tunnels packets regardless
  of where they came from. IP/IP
• Mapping Authentication

13
Mapping doesnt shrink FIB per se

• Mapping appears as FIB entries
• FIB might become larger
• fine-grained multi-homing
• Use Virtual Prefix to shrink the FIB size

14
Virtual Prefixes an Illustration

• Mappings for a given virtual super-prefix are
  stored only at selected routers
• These routers advertise the virtual prefix into
  BGP

Prefix TE Source
Virtual Prefix Adv. 24.0.0.0/8
ETR ---- BGP
24.1.1.0/24 ETR Mapping
ITR2
24.1.1.1
ETR
ETR
24.1.1.1
24.1.1.0/24
24.1.1.1
Customer Site
ITR1
CE2
Prefix TE Source
ETR ---- BGP
ITR2 ---- BGP
24.1.1.0/24 ETR Mapping
24.0.0.0/8 ---- BGP
15
Virtual Prefixes

• Mapping tables and FIBs are smaller, paths might
  be longer
• Few prefixes handle most traffic
• Routers could shed most of their prefixes with
  very little path length penalty
• Save routers from handling large amount of
  mapping updates
• Virtual Prefix vs. Caching

16
Path length versus FIB size (for global IP
routing)
Random across all ISPs
Each ISP has all prefixes
All intra-ISP routes are shortest path
(RIB has around 2000 prefixes)
17
Path length versus FIB size for VPN routing
18
Really small FIBs

• Can shrink the mapping FIB component almost
  arbitrarily
• By chaining tunnels (even within a single POP or
  router)

19
Chained tunnels
20
Conclusion

• CRIO gives us back the path-length / table-size
  trade-off
• We have shown this for global IP and VPNs
• Interesting, but not clear how valuable this is
• Faster and simpler BGP?
• Better multi-homed traffic engineering?
• Smaller FIB?