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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
