1 Evolution Towards Global Routing Scalability draft-zhang-evolution-01 Varun Khare Beichuan Zhang Lixia Zhang IETF74, March 09

Internet Routing Scalability: a problem? DFZ routing table is growing uncontrollably Different parts of the Internet view the scalability problem differently. –Most Stub ASes don’t carry full table internally –Certain ISPs can afford to upgrade routers –Within AS some routers experience problems more severely No unanimous agreement about the problem 2

Growth in DFZ routing table implies following for routers: –FIB size growth –RIB size growth –Increase in Churn due to Edge Dynamics 3 Internet Routing Scalability: a problem?

4 Controlling FIB Size on Old Routers Solution: Virtual Aggregation deployable by single ISP [ViAggre by Ballani et. al., HotNets’ 08] –Don’t need coordination with anyone else –Only need to make change in router configurations –No impact upon routing operations of other networks ViAggre brings immediate FIB reduction

Virtual Aggregation is Map-Encap Map destination prefix to local exit router APR holds Map of detailed prefixes APR encaps packet to BR since other routers don’t know how to reach prefix 5 AS1 PE1 PE3 1/8APR1 APR1 1/8 PE2 1.2/16 PE3 encap decap

Inter-AS overhead of VA If neighboring ASes deploy VA then packet can experience stretch and encap-decap cost in both ASes –Both AS1 and AS2 are mapping destination prefix to their local exit router 6 PE1 APR1 1.2/16 PE3 PE3 PE4 encap decap PE2 1/8 APR1 stretch 1/8 APR2 APR2 encap decap stretch AS1AS2 1.2/16 CE1 CE1 DST 1.2/16

Solve Inter-AS overhead of VA Propagate mapping info across ASes Inter-AS ViAggre [Xiaohu talk IETF74 RTGW] –Only need to Map-encap once –Packet can cross ASes not keeping detailed FIB –Piggyback mapping info on BGP updates 7 PE1 APR1 1.2/16 PE4 PE4 PE2 PE2 PE3 APR2 1.2/16 PE4 PE4 encap CE1 DST 1.2/16 decap AS1 AS2 1/8 APR1 1/8 APR2

RIB size problem After Inter-AS ViAggre –Non-APR routers store full Table with Map Info –APR store routes to virtualized prefixes with Map Info Mapping Table overhead –Same mapping info can be announced through different AS paths –Routers end up storing multiple copies of map info As more ISPs share mapping info, the mapping table will become very big. 8

9 RIB size problem Problem: As more ISPs share mapping info, the mapping table will become very big. –Same mapping info can be announced through different AS paths –Routers end up storing multiple copies of map info PrefixAS-PATHMap Table 1.2/16AS1, AS2Map PE2 1.2/16AS3, AS2Map PE2 AS2 PE 2 1.2/16 BR AS1, AS2 AS3, AS2

10 Solutions to RIB size problem RIB Size ProblemProposed Solution At Internal RoutersNo need to stores routes to virtualized prefixes BRs filter announcement of virtualized prefixes At Border Routers (BR)No need to store full routing table APRs exchange BGP updates with map info on separate BGP session with APRs in neighboring ISPs via multi-hop BGP session At APRsNo need to store multiple copies of map info Upgrade APRs BGP implementation

A side note: whose prefixes get aggregated out? Each ISP will keep its internal routes ISPs will exchange reach ability of their networks –So that an ISP can encapsulate packets from ingress routers to (possibly another ISP’s) egress routers that connect to destination user sites An ISP aggregates out the prefixes that belong to remote (non-direct) users 11

12 Excessive Churn due to edge dynamics APRs share the edge churn load and shield other non-APR routers from it When border (between provider and customer) failure happens –Mapping updates propagated out to ensure best path taken by data packets. –Mapping updates not propagated out and as data packet reaches failed link, provider network handles it by APT’s data-driven redirection. Need to upgrade APRs/routers.

Pushing Mapping Updates 13 Internet Customer AS Y, Prefix P MAP Announcement P Map PE2 Customer AS Z CE MAP Announcement P Map PE2 (change) APR1 X MAP Withdraw P Map PE1 APR 2 APR 90 APR 90 Data Packet

Suppress Mapping Updates 14 Internet Customer AS Y, Prefix P Customer AS Z CE X APT data-driven redirection MAP Announcement P Map PE1 (no change) APR1 Data Packet APR 2 APR 90 APR 90

Evolution towards Scalable Routing VA, LISP and APT are all Map-Encap schemes Propose solution to individual problems rather than a comprehensive solution ISPs decide when to take actions for which problem As ISPs solve individual problems, the routing architecture is steered to scalable routing This talk: to illustrate feasibility of convergence –Not about virtual-aggregation, but take it as first step in the convergence process 15

Evolution –vs– Incremental Deployment New architectural solutions (like LISP, APT) see big benefits when deployed by lots of ISPs Incremental deployment of a new design allow an ISP running new architecture to inter-operate with legacy ISPs, but –Deploying a new design means relatively high cost –Immediate gain can be low In evolutionary path, individual ISPs take actions on their own to solve an immediate problem –Cumulative changes over time can evolve the system to converge towards desired direction 16

Thank You Questions? Comments? 17