[RRG] Re: Granularity & number of ETRs for multihoming

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

I think it would be a serious mistake to introduce a new
architecture on the basis that "single host" EIDs/micronets (single
IPv4 addresses or a /64 for IPv6) was impractical, undesirable or
unlikely to be widely in demand.

If we are stuck with IPv4 for the next decade or two, there will be
a huge demand and need this "single host granularity".  I am unable
to imagine how general Internet users, with the possible exception
of cell-phones, will migrate en-masse to IPv6 without an IPv4
address (public, or private behind NAT).  With IPv4, to be portable
and/or multihomed (conventionally, or with Ivip, a few seconds delay
for inter-ISP mobility) the device or network needs at least one
public IPv4 address.

I think it would be a bad idea to contrive two systematically
different architectural approaches for multihoming based on whether
the end-user had 2 or more ETRs to choose from.  It sounds messy and
bound up in too many assumptions.  The architecture will need to
work well long after these assumptions become invalid.


LISP-ALT, LISP-NERD, APT and Ivip can all technically support single
host granularity.  The question is more about how to scale the
system for the assumed larger number of EIDs/micronets this would
involve.   I think a primary goal of the architecture is that over
the decades to come it be able to scale to very high numbers of
EIDs/micronets - whether they are "single host" or not.  I think
10^8 is a goal for 2020 - and 10^9 or maybe 10^10 in the long-term
future.

Ivip involves no assumptions about the number of ETRs.  The mapping
is from a micronet to a single ETR address.  It is up to the
end-user - who supplies their choice of mulithoming monitoring,
decision-making and mapping update system - how many ETRs they use.


 - 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