Subject: Re: [rrg] AIS - goals

From: Lan Wang <[email-masked]>
Date: Tue, 9 Feb 2010 18:16:36 -0600

Robin,

Thank you very much for your questions.  I'll try to answer some of  
your questions.  Lixia and other members of our team will add their  
comments.

On Jan 31, 2010, at 6:55 PM, Robin Whittle wrote:

> Hi Lixia,
>
> Thanks for pointing out (in an off-list message) that I had
> mischaracterised the goals of "Aggregation with Increasing Scopes: An
> Evolutionary Path Towards Global Routing Scalability".
>
> I wrote (msg05835) that this proposal was aimed at "Improving router
> utilization as a prelude to adopting a solution".  My description in
> msg05835 was also inaccurate except for my note that it:
>
>    suggests it is near-term preliminary to a longer-term
>    host-based solution - implicitly a Core-Edge Elimination scheme.

Your interpretation is not exactly what we meant to say.   We aim to  
solve the routing scalability problem both in the near term and in  
the long term through increasing scope of aggregation.  The following  
paragraph from our proposal says that our solution is orthogonal to a  
host-based solution.  Since a host-based solution will not solve the  
routing scalability problem until a large portion of the Internet  
hosts adopt it, we still need a short-term solution (in our proposal,  
the first two steps FIB aggregation and Virtual Aggregation will  
serve this purpose).  If a host-based solution never gets widely  
deployed, the later steps in our proposal (e.g. inter-AS VA) will  
address the long-term scalability needs.

A major consideration for our work is incremental deployability and  
immediate scalability benefit to anyone who adopts our scheme.  You  
may recall that we started with a map-and-encap scheme APT, which  
falls into the core-edge separation category. However, during the  
past couple of years working on APT, we realized that it is difficult  
for a single entity to deploy APT and receive immediate benefit.  Our  
work has evolved based on this understanding.

>
> This is based on this passage from the PDF version of the proposal:
>
>    Note that our proposal neither interferes nor prevents
>    any revolutionary host-based solutions such as ILNP from
>    being rolled out. However, host-based solutions do not
>    bring useful impact until a large portion of hosts have
>    been upgraded. Thus even if a host-based solution is
>    rolled out in the long run, an evolutionary solution is
>    still needed for the near term.
>
> I apologise for these misleading descriptions, which were based on
> only partially reading the proposal.
>
>
> The RRG Report mentions only two of the three documents:
>
>   The Virtual Aggregation presentation:
>    http://tools.ietf.org/agenda/76/slides/grow-5.pdf
>
>   The ID:
>    http://tools.ietf.org/html/draft-zhang-evolution-02
>
> but does not mention the PDF file:
>    http://www.ietf.org/mail-archive/web/rrg/current/pdfkyygpVszbl.pdf
>
> which was posted to the list in (msg05550).  The RRG wiki link is
> only to the PDF file.

The PDF file on the RRG wiki page is our 2-page summary, as requested  
by the chairs.  The ID http://tools.ietf.org/html/draft-zhang- 
evolution-02 provides more information.  It is cited in the 2-page  
PDF file.  The ID contains a more detailed description of the  
mechanisms.
>
>
> Due to caching constraints, I do not plan to read these fully until I
> have tackled the other proposals.  Based on my partial reading, here
> are some questions which I hope you will be able to answer:
>
>   1 - What are the goals of AIS?  How many non-mobile end-user
>       network prefixes do you plan the system to scale to?
>
>       Brian Carpenter and I have both, independently, suggested
>       that 10 million such networks should be a goal.

Our main goal is to scale routing (i.e. FIB size, RIB size, update  
rate).  We're not aiming at a specific size, and I don't think  
there's a specific upper size limit for our approach.  One reason is  
that there are engineering trade-offs involved.   We have some  
evaluation results in a submitted paper.

>
>       I think we must all expect that in the foreseeable future -
>       to 2020 or 2025 - that the majority of hosts will be mobile
>       hand-held devices.  There really needs to be a mobility system
>       so they can continue their sessions despite gaining and losing
>       multiple addresses in various access networks - including IPv4
>       addresses behind NAT, such as by using WiFi in homes and
>       offices.  I think we should consider 10 billion of these the
>       upper limit.
>
>       "Mobility" is not mentioned in your proposal.  To what extent
>       is AIS intended to support large-scale mobility?

Our position for mobility support is that it is best provided by  
mechanisms outside the routing system.   Here's a paper that  
describes the supporting arguments: "Support Mobility in the Global  
Internet", Lixia Zhang, Ryuji Wakikawa, Zhenkai Zhu. http:// 
www.cs.ucla.edu/~lixia/papers/micnet09.pdf

I'll send another email to answer your remaining questions.

Lan

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 15 Feb 2010 17:43:32 -0800

On Jan 31, 2010, at 4:55 PM, Robin Whittle wrote:

> ......

Robin,

My apology for this belated reply; the team is working on a rebuttal  
and your questions below provided great input. here is just a quick  
reply (may not all be right); better discussions will be in the  
rebuttal text (coming real soon)

> .... Based on my partial reading, here

(AIS = Aggregation with Increasing Scope)
AIS does not have any perceivable upper bound on the number of network  
prefixes it can support.  This is because an AS can reduce its table  
size to a desired value through aggregation, and the mapping between  
aggregated and specific prefixes can be distributed across multiple  
APRs.

>     is AIS intended to support large-scale mobility?

mobility support is considered best supported separately from the DFZ  
routing system.
Another missing item from the proposal is end identifier: We believe  
it is important to have solutions for end identifiers, even though AIS  
does not depend or make use of it.

> 2 - How does AIS support multihoming?  The word does not appear
>     in the proposal documents or the summary.
>
>     How does the multihoming support detect failure of the link
>     between one ISP and the end-user network while detecting that
>     the link from a second ISP is working, and that the second
>     ISP itself is reachable?
>
>     How is this information relayed to or discovered by, the
>     routers (APRs?) which tunnel traffic packets to "egress
>     routers"?

the above are good questions that are not explicitly addressed in the  
500 word solution summary.  Essentially, AIS assumes that BGP works as  
today, thus edge sites following their existing multihoming  
practices.  Transit ASes perform internal FIB/RIB aggregation to  
maintain FIB/RIB size at desired level, without impacting multihoming/ 
TE practices.

Since the network would operate as usual, 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.

> 3 - APRs (Aggregation Point Routers) tunnel traffic packets to
>     "egress routers".
>
>     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
>     they may appear or disappear, and be reachable or not?
>
>     What tunneling protocol do you intend to use?  I assume it
>     would be an entirely ad-hoc arrangement rather than having
>     to maintain two way tunnels to each "egress router".

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 info about  
egress routers are in today's BGP.
The current VA draft suggested 3 (or 4?) options to use as  
encapsulation protocols (IP-in-IP, MPLS, GRE). Each AS may pick one  
that fits its operational practice best; we are also examining whether  
reducing the options would simplify VA design.
the encapsulation is from ingress routers to APRs and APRs to egress  
routers.
There is no tunnels.

> 4 - How will you handle Path MTU Discovery in the tunnels from
>     APRs to "egress routers"?
>
>     At present, I think my IPTM technique [1] and Fred Templin's
>     SEAL [2] are the only protocols which can handle this, though
>     IPTM is Ivip-specific.  Both of them aim to cope with
>     jumboframes as DFZ paths for these develop in the future.
>
>     LISP's approach to PMTUD [3] is not fully developed, and does
>     not send a PTB to the sending host until a second too-big
>     packet arrives.  It needs to be elaborated with checking for
>     an increased PMTU every 10 minutes or so.

AIS does not specifically address the PMTU problem.  The above  
mentioned solutions can work if they get deployed.
I'd also like to make a personal observation here: I heard that MPLS  
ran into PMTU problem in its early days, it eventually went away by  
reducing default MUT size; the same approach has also been used to  
avoid PMTU problem in Apple's MobileMe implementation (which applied  
end-end encapsulation between hosts)

> 5 - I understand that some or ultimately all ISPs would run APRs.
>     I assume that when all ISPs run APRs that this will enable
>     the removal of end-user network prefixes from the DFZ.

All ISPs can run run APRs to reduce their routing table size.
None is required to run APRs to reduce other ASes' routing table size.
One AS runs APRs if and only if it wants to reduce its own table size.

>     When only some ISPs run them, is there any prospect for
>     reducing the number of prefixes advertised in the DFZ?  If so
>     then how would end-user networks whose prefixes were removed
>     receive packets sent by hosts using ISPs without APRs?

the #prefixes can be reduced *between* neighbor ASes doing AIS.
No end user prefixes get removed per se; they get aggregated.

Right after Hiroshima IETF I saw an internet draft floating around (by  
others, not us) to address the issue of retaining routing as is (i.e.  
following precisely today's routing semantics of longest match, in the  
presence of aggregated prefixes by some ASes). I'll find out where  
that draft is now.

> 6 - What advantage would ILNP or any other CEE architecture provide
>     compared to a fully deployed version of AIS?

"a fully deployed version of AIS" does not seem a well formed  
statement, given AIS is a solution for parties who need it.  Although  
a uniform universe would make a simpler picture, it seems that the  
actual deployment of Internet has already led to different practices.
Personal view: such heterogeneity in IP operations is likely going up  
over time.

Back to your question of what advantages a full ILNP or any other CEE  
deployment would bring: I am not sure about advantages or not  
advantages, what I can see as differences are
- major changes in operations in edge networks, to handle multiple
   provider-assigned prefixes
- increased dependencies of the core on all edge networks doing the  
right thing.

> 7 - Do you consider a full AIS deployment to be a Core-Edge
>     Separation architecture, in that it creates a subset of the
>     global unicast address space?

see my comment to the prev question.
in the first evolution draft we envisioned that, if all networks  
deployed virtual aggregation, then the world would converge towards  
(do not know whether it would ever reach) the direction of a core-edge  
separation.

I do not know what you meant by "a subset of global unicast space"...

> 8 - Why would AIS, or AIS supplemented by a CEE architecture, be
>     better than LISP or Ivip?  (I do not consider TIDR to be
>     a solution because it uses DFZ routers for mapping
>     distribution.  I don't yet understand RANGER, but perhaps
>     it too does this.)

regarding LISP: (1)please see the critique I sent out couple days  
back, where I mentioned a basic question of whether one could draw a  
universal division line between "the core" and all edges; one of the  
reasons we gave up APT is because APT also had this model of divided  
world view.  (2) the issue of alignment (or lack of it) between cost  
and gains: if one ISP rolls out LISP, how much could it reduce its  
routing table?
The above two considerations apply to Ivip as well, plus a 3rd one for  
Ivip: as I wrote in my Ivip critique, I question the validity of the  
model of globally synchronized mapping database.

thanks again Robin for the questions; some of them are excellent ones.

Lixia