Subject: [rrg] Corrections to what Lixia said about Ivip

From: Robin Whittle <[email-masked]>
Date: Sat, 27 Mar 2010 04:35:50 +1100

I haven't been able to join the jabber session, but have been
listening to the audio.

Lixia said that Ivip requires changes to routers other than "edge
routers".  I think she meant DFZ routers.  This is only for "Modified
Header Forwarding" as an alternative to encapsulation.  This is
purely optional and is for the the long-term future.  So it is not
not at all required for Ivip to work well.

She also said that Ivip floods all mapping changes, implicitly
everywhere.  The new Distributed Real Time Mapping system involves
potentially large numbers (dozens to hundreds) of independent systems
of DITRs (Default ITRs in the DFZ), where each system generally has
DITR sites widely distributed around the Net.  Each such system
pushes, in real time, mapping changes to its sites for the MABs
(Mapped Address Blocks) that system handles.

This is arguably "flooding", but it is within the one DITR system and
so only concerns the one or few organisations which run this system.
 There are only likely to be at most a few dozen such sites in each
such system.  Each such system only handles a subset of all MABs.  So
this should be perfectly practical and scalable.

ITRs which are handling traffic packets for a given micronet will
still get the updates they need, but these are directed updates.  The
query servers at the DITR sites send updates to the QSR servers
(typically at ISPs) which need to get them, and these QSRs pass this
on to the ITRs.  This cannot be described as "flooding".  ITRs and
QSRs are purely caching devices.

Please take a look at the text and three diagrams at:

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

DRTM could also be used by other CES systems, such as LISP.

  - Robin

---

From: Robin Whittle <[email-masked]>
Date: Sat, 27 Mar 2010 15:27:57 +1100

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

---

From: [email-masked]
Date: Sat, 27 Mar 2010 05:12:23 -0400

Especially: The statement

  "Requires all routers be modified" is not true. 
Lvip as well as some other solutions have been disqualified by this false statement. The default mapper mechanism as of LISP can be used by ANY model for 
 attracting traffic to the  nearest xyz-router of model xyz and GRE-tunneling as to bridge non-xyz-ground.

I thought, this is about research, and not about best-marketing.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Robin Whittle <[email-masked]>
An: RRG <[email-masked]>
Verschickt: Sa., 27. Mrz. 2010, 5:27
Thema: [rrg] The co-chairs do not understand Ivip and some other architectures

Slide 19 in:

is:

                         Ivip

      Map-n-encap edge to edge

Here's what's wrong:

   Map-n-encap edge to edge

  feasibility is a concern

  - Robin

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

=