Re: [RRG] Hosts, DFZ, purity & incremental deployment

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

Short version:   Comparing my notion of "incrementally deployable"
                 with Tony's.  I thought we all agreed on what
                 this meant.

Hi Tony,

I think it would be good to have a clear definition of "incremental
deployability" - if you and I disagree about it so much, others
probably do too.  It is a requirement of the RRG design goals, so we
all need to agree on what it means.

Here is my definition, by way of an example:

Technologies A and B can be installed on hosts, and provide benefits
to the host under different conditions.  A provides benefits for all
the host's communications and B only provides benefits when
communicating with other hosts with technology B.

So in the early days of deployment, when 1 in 10,000 hosts has the
technology:

  Hosts with A gain benefits for 100% of their communications.

  Hosts with B gain benefits, on average, for 0.01% of their
  communications.

Another example, closer to home:

This is for LISP before December last year - without PTRs (Proxy
Tunnel Routers).

The hosts which adopt LISP-mapped addresses (EIDs) and are connected
to a LISP network only get LISP's benefits of multihoming, TE and
portability of addresses for communications from hosts in networks
which also adopted LISP.

So when 1% of networks have LISP, hosts on LISP-mapped addresses
have these benefits for about 1% of their communications.  I think
this would be close to useless, or worse, because it is so
confusing.  My main point is that there is little benefit from
deploying LISP like this, when so few other networks use it.  So
there is little incentive for anyone to deploy it.  So in fact it is
never widely deployed.

(Another example is IPv6, which through no fault of its own, can't
be backwards compatible with IPv4 and therefore suffers the same
problem: initial deployers can only gain benefits from a tiny subset
of their communications, so in fact, the years go by and virtually
no-one really uses it.)

Ivip, or LISP with PTRs, is completely different.

Every host with an Ivip micronet address or LISP EID address
experiences the benefits for 100% of its communications.  This means
there is a genuine incentive to adopt the technology, even when very
few other networks have adopted it.

By my definition, technology B and LISP without PTRs are not
incrementally deployable - and technology A, Ivip and LISP with PTRs
are incrementally deployable.

Yet by your definition, all these technologies are incrementally
deployable because they can be installed on a single host or network
without disrupting anything else.

> I would consider anything that could be rolled out one host at
> a time without breaking anything as being the maximal amount
> of incremental deployability.

Can you suggest any technologies which are not incrementally
deployable by your definition?


Ivip was the first "incrementally deployable" map-encap scheme.  I
am sure I was not the only one to use the phrase in this way at the
time.  LISP became the second, with draft-lewis-lisp-interworking.
Yet I see "increment***" doesn't appear in this draft . . .


  - Robin


--
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