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

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

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

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

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

Path-length / Table size trade-off A nice trade-off to have This trade-off doesn’t exist today  Hierarchical nature of internet “forces” an ISP- centric address assignment model  Because of multi-homing, sites don’t fit neatly into a single “cloud”

CRIO has two parts Mapping/tunneling part  Can operate stand-alone Virtual prefix part  Requires mapping/tunneling

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  Deering’s Map-N-Encap, Kim Claffy et. al.

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

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)

Mapping Dynamics (using agents) ISP1 CE ETR1 ETR2 X ITR Agent prefix withdrawn (via IBGP) mapping invalid (via flooding) Selectively install ISP2

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

Mapping doesn’t 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

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 Customer Site CE /24 ETR ITR1 ITR2 Prefix TE Source ETR ---- BGP ITR BGP /24 ETR Mapping Prefix TE Source ETR ---- BGP /24 ETR Mapping Virtual Prefix Adv / / BGP ETR

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

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

Path length versus FIB size for VPN routing

Really small FIBs Can shrink the “mapping” FIB component almost arbitrarily  By chaining tunnels (even within a single POP or router)

Chained tunnels

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?