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)
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
