Evolution Towards Global
Routing Scalability
draft-zhang-evolution-01
Varun Khare [email protected]
Beichuan Zhang [email protected]
Lixia Zhang [email protected]
IETF74, March 09
1
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
Internet Routing Scalability: a problem?
• Growth in DFZ routing table implies following
for routers:
– FIB size growth
– RIB size growth
– Increase in Churn due to Edge Dynamics
3
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
4
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
1.2/16
AS1
APR1
1/8
decap
encap
1/8
APR1
PE3
PE2
PE3
PE1
5
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
1.2/16 PE3
AS1
encap
encap
1.2/16 CE1
decap
APR1
AS2
PE4
APR2
decap
PE2
PE1
1/8
stretch
APR1
PE3
1/8
stretch
APR2
CE1
DST
1.2/16
6
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
1.2/16
PE4
encap
PE4
PE2
1.2/16
PE4
APR2
AS1
AS2
PE4
APR1
PE2
PE3
PE1
decap
1/8
1/8
APR1
APR2
CE1
DST
1.2/16
7
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
Solutions to RIB size problem
RIB Size Problem
Proposed Solution
At Internal Routers
No 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 APRs
No need to store multiple copies of map info
Upgrade APRs BGP implementation
10
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
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.
12
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