[rrg] The co-chairs do not understand Ivip and some other architectures

Robin Whittle <rw@firstpr.com.au> Sat, 27 March 2010 04:27 UTC

Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C103A6AB8 for <rrg@core3.amsl.com>; Fri, 26 Mar 2010 21:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.546
X-Spam-Level: **
X-Spam-Status: No, score=2.546 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SU79jUI9GaVU for <rrg@core3.amsl.com>; Fri, 26 Mar 2010 21:27:36 -0700 (PDT)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 6A9153A6828 for <rrg@irtf.org>; Fri, 26 Mar 2010 21:27:35 -0700 (PDT)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 22D6917570C; Sat, 27 Mar 2010 15:27:57 +1100 (EST)
Message-ID: <4BAD894D.1010808@firstpr.com.au>
Date: Sat, 27 Mar 2010 15:27:57 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
References: <4BACF076.5090008@firstpr.com.au>
In-Reply-To: <4BACF076.5090008@firstpr.com.au>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [rrg] The co-chairs do not understand Ivip and some other architectures
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Mar 2010 04:27:37 -0000

Short version:   The fact that the co-chairs considered Slide 19 to
                 be a reasonable account of Ivip shows that they
                 completely misunderstand Ivip and its related TTR
                 Mobility architecture.

                 Their Recommendation will be judged according to
                 whatever justifying arguments they supply for it
                 and according to how well they apparently understood
                 all the proposals.

                 They clearly do not understand Ivip or TTR Mobility.

                 Classing GLI-Split as a CES "map-encap" architecture
                 indicates they misunderstand this architecture too.
                 There is no encapsulation.  GLI-Split is a Core-Edge
                 Elimination (Locator / Identification Separation)
                 architecture, as is ILNP.

                 Likewise referring to Name Based Sockets
                 as simply a mapping system indicates they do
                 not understand this architecture either.

                 Both GLI-Split and Name Based Sockets are CEE
                 (Loc/ID Separation) architectures.  I think they are
                 both at least as well documented as ILNP.  I don't
                 support any of these CEE architectures, but the fact
                 that the co-chairs didn't consider ILNP, GLI-Split
                 and Name Based Sockets to be even in the same class
                 is further reason to believe that their
                 Recommendation is based on an inadequate
                 understanding of the architectures.


My previous message was based on what I heard on the audio feed.  Now
I can see the slide with which the co-chairs presented Ivip.

BTW, to call the meeting a "discussion" seems to be inaccurate.
Brief and at times misleading summary material was presented,
followed by a simple Recommendation, without sufficient explanation
of what was wrong with architectures other than ILNP or AIS.  As far
as I can tell, what anyone from the floor said in response to this
did not affect the view of the co-chairs or what they will write in
their Recommendation.  This does not resemble a "discussion".

Lixia, I appreciate you recognising my hard work on Ivip and the RRG
in general, but its just plain misleading to present the following
text as some kind of analysis of Ivip.  I don't understand how you
and Tony could be so uninformed about Ivip and TTR Mobility up to the
last month or so, or Ivip in the last month with Distributed Real
Time Mapping (DRTM), to think this text was accurate.

Slide 19 in:

  http://www.ietf.org/proceedings/10mar/slides/RRG-0.pptx

is:

                         Ivip

      Map-n-encap edge to edge
      Mapping changes are flooded globally and instantly
      The changes include those due to host mobility
      feasibility is a concern
      Requires all routers be modified



Here's what's wrong:

   Map-n-encap edge to edge

      Broadly true, but in the future, whenever all DFZ and some
      other routers can be upgraded, transition to Modified Header
      Forwarding, which avoids encapsulation, its overhead and its
      PMTUD problems.  This is for 10 to 20 years in the future,
      and is not at all necessary for Ivip to deliver immediate
      and lasting benefits to adopters and to scalable routing
      in general.


  Mapping changes are flooded globally and instantly

      With DRTM - which replaces the earlier mapping system -
      each DITR network only "floods" a subset of the mapping
      for the subset of MABs (Mapped Address Blocks) this DITR
      network handles, to the small number of DITR sites in each
      such DITR network.  There would be a few dozen such sites
      at most.

      Each DITR network involves one or at most a handful of
      organisations - so this is surely practical per DITR network.
      There can be large numbers of DITR networks - dozens to
      thousands in principle, though no more than a few dozen is
      likely due to economies of scale favouring the use of an
      established network rather than building another one.

      To the extent that there are scaling problems in any one
      DITR network due to this real-time propagation of mapping
      this does not present a scaling problem for the whole
      Ivip system, because there can be large numbers of such
      DITR networks.

      So it is not true to say the mapping is flooded "globally".
      Each DITR network has at most a few dozen widely (globally)
      distributed sites, and each such network does involve what
      is arguably "flooding" of all mapping changes to these
      sites.  But there are only a few dozen sites and each DITR
      network need only handle a small subset of the total set
      of "edge" address space in the entire system.

      With DRTM, ISPs run ITRs and QSR Resolving Query servers.
      These are both entirely caching devices - but they get
      updates to mapping if they need them, which is not
      "flooding".


  The changes include those due to host mobility

      In a very broad sense this is true, but given that most
      people assume a mapping change every time the MN gets
      a new address, this statement is completely misleading.

      Ivip uses TTR Mobility (which could also be used by LISP):

        http://www.firstpr.com.au/ip/ivip/#mobile

      Mapping changes are not absolutely required no matter
      what new address the MN gets, or where it connects to the
      Net.  Mapping changes are desirable, but not urgently
      required when the MN moves some distance such as 1000km
      or more.  Then, it tunnels to a new, nearby, TTR and after
      that is done, the mapping can be changed to the new TTR.
      Delays in finding and tunneling to a new TTR or in changing
      the mapping to the new TTR do not disrupt communications
      at all.  Many MNs which don't move outside a given city
      or region would probably use the same TTR year after year -
      so there would be no mapping changes.


  feasibility is a concern

      Feasibility of all the proposals is a concern.  You provide
      no explanation of your concerns about the feasibility of
      Ivip with DRTM.


  Requires all routers be modified

      This is completely untrue.   In the long-term future, if and
      when DFZ and some other routers can be upgraded, then Ivip
      will transition from encapsulation to Modified Header
      Forwarding.  But even if that never happens, Ivip with
      encapsulation forever would be far superior to any other
      architecture, for the reasons argued here:

       http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html
       http://tools.ietf.org/html/draft-whittle-ivip-arch
       http://www.firstpr.com.au/ip/ivip/drtm/
       http://tools.ietf.org/html/draft-whittle-ivip-drtm


I haven't looked at the other slides yet, but I think many of them
contain similarly serious errors.  For instance you class GLI-Split
in the CES "Map-and-encap" section - but it does not involve
encapsulation and it is a CEE architecture, since all hosts adopt
Locator / Identifier Separation.

The fact that you consider this completely misleading slide 19 as a
reasonable account of Ivip indicates your misunderstanding of this
proposal is far more significant than whatever it is you do correctly
understand about it.

The Recommendation you are writing is yours alone.  It does not come
from the RRG as a Research Group.  Anyone who wants to estimate how
well informed you were when you made your decision can see that you
were completely misinformed about Ivip, despite Ivip being very well
documented.

  - Robin