[rrg] rebuttal for "Aggregation with Increasing Scope (AIS)"

[Lan Wang <[e-mail]>]

Hi all,

Below is our response to the critiques of our proposal ("Aggregation  
with
Increasing Scopes", or AIS).

A. High-Level Goals and Motivations

1. What are the goals of AIS?  How many non-mobile end-user network  
prefixes will it support?

AIS addresses the routing scalability problem in both near term and  
long term through increasing the scope of route aggregation. AIS does  
not have any perceivable upper bound on the number of network  
prefixes it can support, because an AS can reduce its table
size to a desired value using virtual/aggregated prefixes, and the  
mapping between
aggregated and specific prefixes can be distributed across multiple  
APRs.

2.  To what extent is AIS intended to support large-scale mobility?

Mobility support is considered best supported separately from the DFZ
routing system (see "Support Mobility in the Global Internet",
http://www.cs.ucla.edu/~lixia/papers/micnet09.pdf)

As mobility and host multihoming become pervative, a development of  
end identifiers becomes increasingly urgent. AIS is orthoganal to end  
identifier deployment: it does not depend on or impact it in any way.

3. Why would AIS, or AIS supplemented by a CEE architecture, be
     better than LISP or Ivip?

AIS aims to be deployable by any single party to get immediate  
benefits in routing scalability, without impact on any other  
networks.  Most other proposals, including LISP and Ivip, face the  
problem of cost-benefit alignment (or lack of it): If only one ISP  
rolls out LISP, it is questionable how much it can reduce its routing  
table.

Our earlier proposed solution, APT, falls into the same core-edge  
separation category as LISP and Ivip.  However, a basic question to  
this global separation approach is whether
one could draw a universal division line between "the core" and all  
edges given the complexity of real-world operation. In addition, Ivip  
also relies on a globally synchronized mapping database, whose  
feasibility remains an open issue.

4.  Do you consider a full AIS deployment to be a Core-Edge
     Separation architecture?

If all networks eventually deploy AIS, the result would look similar  
to a core-edge separation architecture. One difference in AIS is that  
each network can makes its own decisions on the degree of prefix  
aggregation.  AIS does not demand a universally agreed upon division  
of the "core" and "edges" (see the answer to question 3).

5. What advantage would ILNP or any other core-edge elimination (CEE)
    architecture provide over AIS?

In terms of routing scalability, ILNP or other CEE solutions require  
major changes to hosts and application implementations, and routing  
table size will not shrink till a wide deployment at end-hosts.  
Meanwhile, some networks will need a short-term solution, and the  
first two steps in our proposal, FIB Aggregation and Virtual  
Aggregation can serve this purpose.  If ILNP does not get widely  
deployed, inter-AS VA can extend scalable routing to broader scopes.  
On the other hand, if ILNP is eventually deployed, AIS has no impact  
on ILNP deployment occurring at edges but can help keep routing table  
size in ISPs under control while ILNP takes its time to roll out.

6.  Would an evolutionary approach end up with adding
     more and more patches on the old architecture, and not lead to a
     new architecture as the proposal had expected?

The basic approach to routing scalability is prefix aggregation,  
which is the essence of AIS as well as other solutions.  That is why  
we believe AIS's increasing scope of aggregation is heading in the  
right direction.  LISP, Ivip and ILNP also aim to allow the ISPs to  
aggregate prefixes, the only difference between AIS and these other  
solutions lies on how to enable aggregation. LISP and Ivip remove  
"edge prefixes" by moving them to a mapping table; ILNP gets rid of  
edge prefixes entirely by putting the edge and provider mapping into  
DNS. AIS lets each network control and manage its own mapping between  
specific and aggregated prefixes. All the solutions will add  
complexity into the overall system; it's just a matter of where the  
complexity goes, e.g., ISPs versus end-user networks.


B. Technical Issues

1. How does AIS support multihoming? How does the multihoming support
    detect failure and recovery of the links?

Essentially, AIS assumes that BGP works as today, thus edge sites  
following
their existing multihoming practices.  Failure detections between
edge sites and their ISPs are handled by routing protocols as today.
The mapping information between aggregated prefixes (virtual prefix)
and the specific ones comes directly from BGP routing updates.

2. How many APRs and "egress routers" would there be?  Where would  
they be?
    How do the APRs know where all the "egress routers" are?

How many APRs to have is an engineering question, taking into account
APR mapping data size, traffic load, the number of major POPs an AS
may have, minimizing path stretch, etc.  The number of egress routers  
is what an
AS has today.  All information about egress routers are carried in  
routing announcements, the same operation as in today.

3. How will you handle Path MTU Discovery in the tunnels from APRs to  
"egress
    routers"?

AIS does not specifically address the PMTU problem. MPLS
ran into PMTU problem in its early days, it eventually went away by
reducing default MTU size; the same approach has also been used to
avoid PMTU problem in Apple's MobileMe implementation (which applied
end-end encapsulation between hosts).

4.  When only some ISPs run them, is there any prospect for
    reducing the number of prefixes advertised in the DFZ?

Even if only a single ISP takes this approach, its routing table size  
can be greatly reduced. End user prefixes are not removed per se;  
they're aggregated
into less specific prefixes within the network who deploys AIS.

5. FIB aggregation, at level-3 and level-4, may introduce extra
    routable space.

As mentioned in our INFOCOM 2010 paper (see below for the reference),
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.

X. Zhao, Y. Liu, L. Wang, B. Zhang, "On the Aggregatability of Router
Forwarding Tables," to appear in IEEE INFOCOM 2010

6. 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.

We have evaluated the impact of virtual aggregation on path stretch and
found that the increase in packet delivery delay is minimal.  The  
results
are in the following papers:

Making Routers Last Longer with ViAggre
Hitesh Ballani, Paul Francis, Tuan Cao and Jia Wang
USENIX NSDI 2009, Boston, MA, April 2009.

Evolution Towards Global Routing Scalability
V. Khare, D. Jen, X. Zhao, Y. Liu, B. Zhang, D. Massey, L. Wang, L.  
Zhang
Under review (available upon request).

We will investigate other potential side-effects of VA.

7. FIB Aggregation and Virtual Aggregation may require additional
    operational cost.

We are currently working on a detailed evaluation of the design  
tradeoffs
associated with FIB aggregation, so that operators will have enough
information to select the best option for their networks.   For virtual
aggregation, we expect to work out a simplified version which will be  
easier to
understand, implement and deploy.

Lan Wang (on behalf of the AIS team)