Subject: [rrg] Ivip Critique

From: Lixia Zhang <[email-masked]>
Date: Mon, 18 Jan 2010 23:42:06 -0800

Robin and I have had a few rounds of text revisions. Since the  
deadline is fast approaching, here is my latest version.

Lixia
-----------

Ivip Critique

Looking at 1000 feet level, Ivip shares the basic design approaches with
LISP and a number of other Map-n-Encap designs based on the core-edge
separation.  However the details differ substantially. Ivip design takes
a bold assumption that, with technology advances, one could afford to
maintain a real time distributed global mapping database for all
networks and hosts. Ivip proposes that multiple parties collaborate to  
build a mapping distribution system which pushes all mapping  
information and updates to local, full database query servers located  
in all ISPs within a few seconds.  The system has no single point of  
failure, and uses end-to end authentication.

"Real time, globally synchronized mapping database" is a critical  
assumption in Ivip. Using that as a foundation, Ivip design avoids  
several challenging design issues that LISP team has studied  
extensively, which include
(1) special considerations of mobility support which adds additional  
complexity to the overall system;
(2) prompt detection of ETR failures and notification to all relevant  
ITRs, which turn out to be a rather difficult problem; and
(3) development of LISP-ALT lookup sub-system. Ivip assumes the  
existence of local query servers with full database with the latest  
mapping information changes.

However to be considered as a viable solution to Internet routing  
scalability problem, Ivip faces two fundamental questions.  First, it  
is an entirely open question whether a global-scale system is able to  
achieve real time synchronized operations as assumed by Ivip.  Past  
experiences suggest otherwise.

The second question concerns incremental rollout. Ivip represents an  
ambitious approach, with real-time mapping and local full database  
query servers - which many people regard as impossible.  Developing  
and implementing Ivip may
take fair amount of resources, yet there is an open question regarding  
how to *quantify* the gains by first movers - both those who will  
provide the Ivip infrastructure and those which will use it.  
Significant global routing table reduction only happens when a large  
enough number of parties have adopted Ivip. The same question arises  
for most other proposals as well.

One belief is that Ivip's more ambitious mapping system makes a good  
design tradeoff for the greater benefits for end-user networks and for  
those which develop the infrastructure. Another belief is that this  
ambitious design is not viable.

---

From: Robin Whittle <[email-masked]>
Date: Tue, 19 Jan 2010 19:54:54 +1100

Folks, Lixia bounced drafts to me so I could correct any
misunderstandings - I really appreciate this.

This is a pretty "1000 foot view" critique, and ideally there would
be more detailed discussion of the most challenging or contentious
aspects of Ivip.  But the co-chairs can't be expecting lots of detail
in 500 words.

There's time and space for more detailed discussion on RRG list - and
at 371 words, there's space for other people adding something to what
Lixia wrote.

I am revising ivip-db-fast-push to 03 and hope to get back to
critiques in the next few hours.

  - Robin

---

From: Tony Li <[email-masked]>
Date: Thu, 21 Jan 2010 10:28:43 -0800

Lixia Zhang wrote:
> Robin and I have had a few rounds of text revisions. Since the deadline 
> is fast approaching, here is my latest version.

Received and incorporated.

I noted that there was no comment on the MTU issue.  Should there be?

Tony

---

From: Robin Whittle <[email-masked]>
Date: Fri, 22 Jan 2010 18:11:37 +1100

Hi Tony,

> I noted that there was no comment on the MTU issue.  Should there be?

I am not sure what you are referring to.

Ivip is intended to run in the long-term, and ideally from the start,
with Modified Header Forwarding rather than encapsulation - thereby
avoiding the Path MTU Discovery problems which arise from encapsulation.

  ETR Address Forwarding (EAF) - for IPv4

     http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01

  Prefix Label Forwarding (PLF) - for IPv6

     http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/

Without these, I think Ivip would still have many advantages, so they
are not essential parts of Ivip.  There has been only a little debate
about these.

They both require upgrades to all (or almost all) DFZ routers and
some other routers.  In the long-term, this is not a problem since
new routers could be built and programmed to handle the new
functionality.

There are various things which could be debated, such as whether
these approaches would work and whether this would be a good use for
these header bits.

Also, there is the question of how much effort and expense would be
required to upgrade the routers, for instance, for IPv4
implementation later this decade - so as to avoid the need to do
encapsulation at all.   Since I think there's less of a hurry for
IPv6, I figure there's a much greater chance of having the routers
ready for whenever Ivip is introduced for IPv6.   Any router with a
firmware controlled FIB should be upgradeable without too much fuss.

There's space for someone to write a critique of this aspect of Ivip,
or to add to what Lixia wrote with any other concerns.

  - Robin