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.
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
