Subject: [rrg] AIS - goals and techniques

From: Robin Whittle <[email-masked]>
Date: Mon, 01 Feb 2010 11:55:03 +1100

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.

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.

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.

      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?

  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"?

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

  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.

  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.

      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?

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

  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?

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

  - Robin

[1] http://www.firstpr.com.au/ip/ivip/pmtud-frag/
[2] http://tools.ietf.org/html/draft-templin-intarea-seal-08
[3] http://tools.ietf.org/html/draft-ietf-lisp-06#section-5.4.2