Subject: [rrg] critique of "Aggregation with Increasing Scopes"

From: Beichuan Zhang <[email-masked]>
Date: Mon, 18 Jan 2010 23:13:57 -0700

Hi,

Lan Wang and I put together the following critiques on our proposal  
"aggregation with increasing scopes". It's a summary of comments our  
team has collected, mainly from past RRG meetings and emails.

---
beichuan

-----------

All the RRG proposals that scale the routing share one fundamental  
approach, route aggregation, in different forms, e.g., LISP removes  
"edge prefixes" using encapsulation at ITRs, ILNP achieves the goal by  
locator rewrite. In this evolutionary path proposal, each stage of the  
evolution applies aggregation with increasing scopes to solve a  
specific scalability problem, and eventually the path leads towards  
global routing scalability. E.g., it uses FIB aggregation at single  
router level, virtual aggregation at network level, then between  
neighbor networks at inter-domain level.

Compared to others, this proposal has the lowest hurdle to deployment,  
because it does not require all networks move to use a global mapping  
system or to upgrade all hosts, and it is designed for each individual  
network to get immediate benefits after its own deployment.

Critiques to this proposal fall into two types.  The first type  
concerns several potential issues in the technical design as listed  
below:

(1) FIB aggregation, at level-3 and level-4, may introduce extra  
routable space.  Concerns are raised about the potential routing loops  
resulted from forwarding otherwise non-routable packets, and potential  
impact on RPF checking.  These concerns can be addressed by choosing a  
lower level of aggregation and by adding null routes to minimize the  
extra space, at the cost of reduced aggregation gain.

(2) Virtual Aggregation changes the traffic paths in an ISP network,  
hence introduces path stretch. Changing the traffic path may also  
impact the reverse path checking practice used to filter out packets  
from spoofed sources.  More analysis is need to identify the potential  
side-effects of VA and to address them.

(3) The current Virtual aggregation description is difficult to  
understand, due to its multiple options for encapsulation and popular  
prefix configurations, which makes the mechanism look over- 
complicated. More thought is needed to simplify the design and  
description.

(4) FIB Aggregation and Virtual Aggregation may require additional  
operational cost.  There may be new design trade-offs that the  
operators need to understand in order to select the best option for  
their networks. More analysis is needed to identify and quantify all  
potential operational costs.

(5) Different from a number of other proposals, this solution does not  
provide mobility support. It remains an open question whether the  
routing system should handle mobility.

The second type of critique concerns whether deploying quick fixes  
like FIB aggregation would alleviate scalability problems in the short  
term and reduce the incentives for deployong a new architecture; and  
whether an evolutionary approach would end up with adding more and  
more patches on the old architecture, and not lead to a fundamentally  
new architecture as the proposal had expected.  Though this solution  
may get rolled out more easily and quicker, a new architecture, if/ 
once deployed, could solve more problems with cleaner solutions.

---

From: Tony Li <[email-masked]>
Date: Thu, 21 Jan 2010 01:37:58 -0800

> team has collected, mainly from past RRG meetings and emails.

Received and incorporated.

Tony