Subject: [rrg] Proposals which match rrgarchitectures.html

From: Robin Whittle <[email-masked]>
Date: Tue, 30 Dec 2008 16:40:28 +1100

Here is my attempt to state which proposals match the various parts
of Bill's page (Draft 6):

  http://bill.herrin.us/network/rrgarchitectures.html

I have no idea how to match the Strategy B variants to various
proposals, so I hope someone will clarify this.  Likewise D and E.
Please suggest corrections and I will write up a final version at:

  http://www.firstpr.com.au/ip/ivip/rrgarch/

   - Robin

Strategy A

   These are core-edge separation schemes, with the new functionality
   being implemented in the network (in or near DFZ, ISP and end-user
   CE routers, but also for internal routers for Ivip forwarding
   approaches).  Will work with existing hosts (except that Ivip
   forwarding and PMTUD management won't accept fragmentable
   packets longer than a certain size.)

   LISP in all its variants.
   APT.
   Ivip.
   TRRP.
   Six/One Router (for IPv6 only).

   A paper arguing for this class of solutions (core-edge separation)
   and against the "elimination" class (Strategy B) is:

      Towards a Future Internet Architecture: Arguments for
      Separating Edges from Transit Core
      Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang
      http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf

   A1a, A1b, A1c.

      I am not sure about these.  Bill and I are discussing them:

        http://www.irtf.org/pipermail/rrg/2008-December/000591.html

      I also discuss potential improvements to the parts which
      describe Ivip's forwarding approaches.

   A2a   LISP-NERD.

   A2b   Ivip and APT are covered by this, but it is not a complete
         description of either.

   A2c   LISP-ALT and TRRP.

         Where is Six/One Router covered?  It doesn't have a specific
         mapping distribution system, but I guess A2c is a likely
         approach.

   A3a   LISP, APT, TRRP and Six/One Router.

   A3b   Ivip.

   A4a   No proposals I can think of match this.

   A4b   Likewise.

   A4c   I am not sure, but this might apply to the PMTUD approaches
         of LISP, APT and TRRP.  AFAIK, LISP has no such approach.
         I am not sure how APT or TRRP will handle it.

         Six-One router and Ivip's forwarding modes have no PMTUD
         problems.

   A4d  Ivip.

   A4e  Six/One Router (IPv6 only).

   A4f  Ivip's Prefix Label Forwarding (PLF) - for IPv6.

   A4g  Ivip's ETR Address Forwarding (EAF) - for IPv4.

   A5a  AFAIK, this applies to all of this class of proposal:
        LISP, APT, Ivip, TRRP and Six/One Router.

   A5b  } I don't know of any proposal which matches these.
   A5c  }

Strategy B

   This is (roughly, exactly?) the elimination class of proposals.

   This requires new host functions, including AFAIK, changes to
   host stacks, APIs and applications.

   No-one is suggesting such a solution for IPv4 - they are all
   modifications to IPv6, I think.

   ILNP is one such proposal, I think.

   HIP may be another.

   However neither of these is fully documented as a solution to the
   routing scaling problem.

   Can anyone confirm this or suggest other proposals?

   Can anyone write about B1x and B2x with respect to actual
   proposals?

Strategy C

   Geographic aggregation.  Heiner Hummel has been proposing this for
   at least a year - but there is no substantial documentation of
   this or any other such proposal.

   Compact routing perhaps?  See critique:

     On Compact Routing for the Internet
     Dmitri Krioukov, kc claffy, Kevin Fall, Arthur Brady
     ACM SIGCOMM CCR, v.37, n.3, p.41-52, 2007
     http://arxiv.org/abs/0708.2309

Strategy D

   FIB compression for DFZ routers.

   What proposals match this?

Strategy E

   Billing system for advertising each prefix in the DFZ.

   Have there been any such proposals?  AFAIK, none have been
   suggested seriously in RAWS, the RAM list or the RRG.

Strategy F

   NOP.

Strategy G

   The original vision of IPv6, with hope that those who wanted to
   multihome would get two or more ISPs and use SHIM6.  (But this
   is IPv-6 only, offers network operators no obvious network-centric
   controls - and only works if the other host has SHIM6 too.)

_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: He Yan <[email-masked]>
Date: Mon, 29 Dec 2008 23:04:16 -0700

>         mapping distribution system, but I guess A2c is a likely
Hi Robin,
I believe APT is covered by A2c, not A2b.
In APT, Default mapper has all the mappings and Encoder/ITR request  
and cache individual mappings when needed.

Thanks,
He Yan

---

From: Robin Whittle <[email-masked]>
Date: Tue, 30 Dec 2008 17:41:08 +1100

Hello He,

> In APT, Default mapper has all the mappings and Encoder/ITR request and
> cache individual mappings when needed.

I agree.  I think these are poor descriptions of the various mapping
systems - but only Ivip matches A2b's "real time".

A2c matches APT if we assume the Default Mappers constitute a
"distributed registry".

Dan, can you confirm that A2c covers APT?

When I mentioned Compact Routing, for Strategy C, I did not mean to
imply it was the same as "Geographic Aggregation".  As far as I know,
Compact Routing matches the overall description of Strategy C, but
would have its own variant, such as C2.

  - Robin

---

From: Robin Whittle <[email-masked]>
Date: Tue, 30 Dec 2008 19:19:29 +1100

I included compact routing:

  http://arxiv.org/abs/0708.2309
  http://www.aladdin.cs.cmu.edu/workshops/netdes2/slides/gavoille.pdf

as a proposal which I thought matched Bill's Strategy C:

However, this was with only a moment's thought and without any proper
understanding of compact routing.  It is not a proposal which the RRG
has discussed in any depth.  The messages where it was mentioned are
listed below, but there was no substantial discussion in these or the
replies.

It has been suggested to me offlist that maybe it doesn't match
Strategy C.

Unless someone suggests it matches the Strategy C description - or
unless there is a new category for it, I won't mention it.

  - Robin

  http://psg.com/lists/rrg/2008/msg00358.html  2008-02-18
  Jari Arkko

  http://psg.com/lists/rrg/2008/msg02456.html  2008-09-12
  Dimitri Papadimitriou

---

From: Dan Jen <[email-masked]>
Date: Tue, 30 Dec 2008 18:20:36 -0800

Hi all,

> Dan, can you confirm that A2c covers APT?

None of the A2s fit APT exactly.  Since all the default mapper systems
hold full mapping tables, as a set they don't really constitute a
'distributed registry'.  But, TRs do query their local default mappers
and cache replies, so maybe A2c comes closest to describing APT.

- Dan Jen

---

From: "William Herrin" <[email-masked]>
Date: Tue, 30 Dec 2008 22:07:07 -0500

> and cache replies, so maybe A2c comes closest to describing APT.

Hi Dan,

If I correctly understand APT (please correct me if I get it wrong),
the default mappers contain ITR functionality. Packets sent to them
are encapsulated and sent towards an ETR.

Next, you layer on the TRs which accelerate the process. Packets to be
encapsulated go to the TRs first where a fast, small cache of
destinations is consulted. When the TRs encounter a packet they don't
currently know how to map, they forward it to the default mapper. In
addition to encapsulating the forwarded packet, the default mapper
installs a map entry in the TR's cache so that it can handle
subsequent packets with the same destination on its own.

The default mapper keeps track of the caches in the specific TRs that
it serves. When a map affecting one of the cached entries changes, the
default mapper updates the TR's caches with the new map. Because the
mapper is authoritative for the specific TR's entire cache, it gets
around the change notification failure problem from
http://bill.herrin.us/network/statechange.html . TTLs and other
techniques for expiring the cache aren't necessary; the default mapper
handles it.

Although the TRs and their default mapper are physically separate
pieces of equipment and may not be at the same physical location, they
are logically one ITR node which doesn't function without both
components.

If that description is accurate, the heart of the system is the
default mappers which exist in every APT network. How do the default
mappers get those full maps? Periodically (A2a) with the expectation
that the default mapper must determine which remote ETRs are presently
successful or continuously (A2b) as they change to match the currently
functioning network topology?

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Dan Jen <[email-masked]>
Date: Wed, 31 Dec 2008 02:51:51 -0800

Hey Bill,

> are encapsulated and sent towards an ETR.

So far so good.  Each ISP should have 1 or more default mappers.

> subsequent packets with the same destination on its own.

Right.

> techniques for expiring the cache aren't necessary; the default mapper

Actually, in older drafts of APT, default mappers did not keep track of
the cache state in TRs.  We thought this added too much additional
complexity to the default mappers.  The TRs used TTLs to expire stale
mappings.  

However, since default mappers are only responsible for their own TRs
(at most the # of TRs in the ISP), it may not be out of the question to
do what you described.  When we begin implementation and simulation of
APT, we will get a better idea of how much a default mapper can handle.

> functioning network topology?

Well, we do A2b for MAPPING changes, meaning a change of the set of
providers serving a customer, or a TE preference change.  However, link
state dynamics(reachability status of provider to customer) do not cause
mapping updates.  Failures are handled using data-driven notifications,
where only parties attempting to send data through a failed
customer-provider link are notified of the failures.  See section 6 of
http://tools.ietf.org/html/draft-jen-apt-01 for a deeper explanation of
what I'm talking about.

Of course, we modify APT as we gain a better understanding of the
problem and solution space, so the above isn't set in stone.

- Dan Jen