Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared

Hi Fred,

Thanks for clarifying my understanding of IPvLX to some extent.  I
still don't have anything like a clear enough understanding of it
to compare it with the other schemes.

Is IPvLX intended to help with IPv4 in respect of multihoming,
portability, TE, splitting up existing space into finer and more
flexibly used sections for more users and/or with  reduction in
BPG advertisements and/or churn in IPv4?

If not, then as with Six/One, I don't think IPvLX helps with the
most pressing problems of the foreseeable future - and so is not
comparable to LISP, eFIT-APT or Ivip.

If your proposal does help with IPv4 communications, with
non-upgraded hosts - for instance resulting in immediate or
long-term reduction in the size of the global BGP routing table,
and/or in improvements to multihoming, portability or TE then it
would be great if you could explain on the list exactly how this
works, with network diagrams, examples of deployment etc.

Can IPv4 hosts on non-upgraded networks send packets to IPv4 hosts
on upgraded networks?  If not, then I think IPvLX suffers from the
same problem as LISP-NERD or LISP-CONS - and so is not
incrementally deployable because early adopters (really any
adopters until adoption is universal) suffer loss of reachability
Early adopters suffer the worst costs or barriers, since hosts in
virtually no other networks will be able to reach their hosts.

Although there is no detailed documentation of how eFIT-APT could
be incrementally deployed (at least in terms of reachability and
what is and is not advertised in BGP), I imagined a way it could
be done while retaining reachability from non-upgraded networks.
However, this defers the reduction in the size of the BPG routing
table until either all networks are upgraded, or until enough of
them are that some upgraded networks don't mind about not being
reachable from those networks which are not - and so stop
advertising their prefixes in BPG.

How does IPvLX handle the requirement that a multihoming system
short-term changes to traffic flow?  I think service restoration
for a multihomed link is an example of what Eliot called
"operational state"?  This is an important aspect of architectural
goals in which Ivip differs completely from LISP or eFIT-APT.

LISP-NERD/CONS and eFIT-APT all have slow-changing databases which
carry instructions for the ITR-ETR system on how to cope with
short-term traffic flow requirements, such as loss of reachability
on one link, requiring packets to be tunneled to another ETR in
order to restore communications.  The short-term decisions are
made by the ITR-ETR and the mapping data does not change at all
during multihoming service restoration.  This means a more complex
database and *much* more complex ITR-ETR functionality, with much
more communication between ITRs, ETRs and in some cases recipients
of tunneled packets which are not ETRs which are ready to handle
the packets.  This introduces a much greater burden of complexity
in order to adequately protect against attacks and other security
problems.

In short, LISP-NERD/CONS and eFIT-APT all card-code short-term
behavior into the system itself, and make it configurable to some
extent by parameters in the mapping database.

Also, LISP-NERD/CONS and eFIT-APT do not attempt to assist with
mobile-IP - because their database distribution systems are too
slow with a mobile host's requirement that traffic flow to one ETR
or another in the different networks it has connections with.

Ivip is completely different.  The database is simple and intended
to be very rapidly changed.  Ivip does not attempt any
reachability testing or require its ITRs or ETRs to make any
decisions, such as for TE, multihoming service restoration or for
mobility.  This means Ivip can be used to support with mobile IP
just as it supports multihoming restoration, portability, finer
splitting of the address space among many more end-users etc. -
without actually containing any special database information or
ITR functions to support these separate applications.

Ivip more closely follows what I think is a common IETF
philosophy: single function, open-ended, building blocks which can
be used in combination with other building blocks to solve a wide
variety of problems, without having to create a monolithic system
for each particular problem.  (I don't know of a formal statement
of this, but it is evident from the whole nature of TCP/IP design,
DNS,  HTTP etc.)

Assuming IPvLX helps with ordinary IPv4 communications, it would
be great if you could explain on this list how IPvLX would be
deployed:

  Give a fully detailed example of the BGP or other benefits it
  brings to IPv4, and of how IPv4 packets flow in both
  directions between hosts in firstly two upgraded networks and
  secondly in one upgraded and one non-upgraded network.

  Describe the possible placement of upgraded or new routers.

  Describe the new features which are required in routers and
  how feasible these are to implement in the FIBs of current
  routers, with firmware upgrades.  The rest has to be done
  in the main CPU.  In both cases, it is important to discuss
  the communications, CPU and memory requirements of these new
  features for a reasonably widely deployed scenario.  Also,
  in the long-term future, can scaling be achieved by
  parallel routers, servers etc. rather than having to ramp
  up performance of routers which can't have their load split
  amongst others.  (eFIT-APT seems to suffer here, because all
  the ITR and ETR work has to be done in Customer Edge routers
  of provider networks.)

  Examples of packets which are used in IPv4 host communications
  and separate examples for IPv6.

  What other servers, databases, distribution systems etc.
  are required.

Then, ideally, you could write something about IPvLX for each of
the underlines headings in my comparison.

I would link to your message in the list or perhaps splice this
into my page:

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

    - Robin

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram