[RRG] He|p wanted for Ivip

[Robin Whittle <rw@firstpr.com.au>]

I haven't had time yet to catch up on the recent discussions.

I am keen to for other people to he|p with Ivip.  This includes
criticising the proposal and using whatever they like about Ivip in
other proposals.

The purpose of Ivip is to he|p with the routing and addressing
problem, and hopefully to provide two things which other proposals
(LISP, eFIT-APT and TRRP) don't try to achieve:

  Support for efficient, enhanced, mobility for both IPv4 and IPv6.

  Enhanced utilisation of IPv4 address space.

Another feature of Ivip I haven't mentioned is that it is easy to
scale the ITR system to any traffic load, whatever the limitations
of individual ITRDs (full database ITRs), by having some of them
advertise (internal routing or BGP) one subset of the Ivip-mapped
address ranges, while other ITRDs advertise other subsets.

Whether the final architectural change is called Ivip or not doesn't
matter.  If Ivip contributes a single good technical principle, or
illuminates a single significant mistake which can be avoided, then
it will have served its purpose.

However, Ivip is currently intended to be developed into the best
possible complete solution for the IPv4 and IPv6 routing and
addressing problems, not counting whatever enhancements are made to
BGP.  This is for the near-term - a 3 to 15 year timeframe - to be
compatible with existing hosts and with as many existing routers as
possible.


My wife Tina and I have to concentrate on earning a living, so I
will not be able to work on Ivip as intensively as I did in the
month to mid July when I finished the Ivip Internet Draft, and the
next month or so when I wrote a bunch of things for the website and
was involved intensively in mailing list discussions.

We live in Melbourne, Australia and there is no prospect of me
attending an IETF meeting in the foreseeable future.  However, if
someone can create a phone, VoIP or video conferencing link to the
meeting, I would be keen to participate as best I can.

I am in independent researcher, as is Bill Herrin.  Bill's TRRP proposal

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

shares an important goal with Ivip, which is not a goal of the other
proposals to date: to enable fast control of the global ITR system
by the end-user, enabling them to construct their own multihoming
service restoration system.  This is a conceptually simpler,
component-based, approach - in contrast to the other proposals which
are too slow to support enhanced forms of mobility, and which
therefore build the very difficult task of multihoming service
restoration into the protocol and into the ITR's functionality.

(We are now probably past the start of the message where the list
server bounces the message if the word "help" appears.)

I can't speak for Bill, but what I suggest below for helping with
Ivip may well apply to TRRP as well, since these proposals share
some common goals and are, so far, the product of one individual's
efforts.

Some ways of helping:

   Read the Internet Draft and criticise, analyse or discuss it on
   the RRG list.

   Copy or adapt any or all parts of Ivip - ideally with proper
   attribution - for existing or new proposals.

   For those who attend the next RRG meeting - where a comparative
   discussion of the various proposals might take place - be
   informed enough about Ivip to criticise it or explain its
   benefits.

   Work directly with me - via email and or phone (I can call you)
   on improving Ivip.  This includes criticising the proposal and
   pointing out how the ID and web pages could be improved.

You don't have to think that Ivip is the best approach to help in
improving it and/or in criticising it so that other proposals can
avoid whatever is wrong with Ivip.

Ideally, I would like to be part of a team of people working on Ivip
or something like it.  Right now, I would simply appreciate one or a
few people reading the ID and working with me to discuss and
hopefully improve the proposal.

The current ID has a vision of the Replicator system which is
conceptually OK, but the exact details of how the data should be
transmitted need to be revised.  I am thinking of some kind of
multicast-like UDP stream where the packet contents can be quickly
authenticated, or at least where spoofed packets can quickly be
detected so the changes they made to the ITRD's (or QSD's) database
can be quickly reversed.  Also, I am thinking of the ITRD or QSD
receiving one or two separate streams of mapping data so the chance
of one packet being missing in both streams is relatively low - with
a separate HTTP based approach to requesting the information
contained in packets which were missing from the stream.

I believe the value of a real-time (a few seconds, ideally) updated
global system of ITRs will be immense.  If something slower - such
as LISP - is built, I am sure a bunch of people will soon want to
soup it up for real-time control like Ivip.

It doesn't seem to be impossible or too costly to achieve this
realtime control.

If people are now, or soon to be, using the Net for full quality
video, this level of data is comparable to that required for a
global, mobile-supporting, mapping database update stream such as
Ivip proposes.  If the sum of all these data streams is too much for
any one ITR or replicator system, then multiple parallel systems can
be built, with some ITRs handling some parts of the mapped address
space and others handling other parts.
	
  - Robin         http://www.firstpr.com.au/ip/ivip/


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg