[RAM] Ivip (was ViP ...)

Sorry this is so long.  I figure one long message is better than
many short ones.

Below I respond to questions raised by Dino and Christian in "ViP:
Anycast ITRs in the DFZ & mobile tunnels".  I will reply to Ved
about NEMO in a separate message.

I am now calling this proposal Ivip, for reasons given below.

I am developing this proposal by thinking out loud on this list,
because my first proposal (SRAM mapping of the FIB) was a lot of
work in isolation and turned out not to be directed at the most
important problem.

The easiest way to get the feel of what I intend Ivip or LISP to do
is to imagine this as a plumbing problem.

Despite whatever improvements might be made to BGP, it seems we have
to accept that the Internet can only have about X many "pipes"
(divisions of the address space) by which the BGP routing system can
physically move packets to border routers.  The current value of X
is above 200,000 and we are hoping it won't grow to much more than
double this for a decade or two.  But natural growth would see it
double in a few years.

I think the task is to provide millions of end-users - ideally tens
or hundreds of millions of end-users, including companies, schools
and SOHO people - with the same experience as if they had their own
portable "pipe" they could take to various ISPs.  For multihoming,
they need two links to two ISPs, and they need to switch the
Internet's pipe for their address, or subnet of addresses, from one
ISP to another.

So we need a system which makes a 300,000 (relatively fixed) pipe
system behave much as if it had millions or tens of millions of more
flexible pipes.

Both LISP and Ivip do this by putting multi-pipe receptors (ETRs) in
the edge networks, either at border routers or inside the edge networks.

Both LISP and Ivip have a central system determining how the pipe
endpoints are pointed to the ETRs.  The difference is that the
pipe's inputs with LISP must be inside or at the border of the edge
networks of the sending hosts, while for Ivip, they can be either at
the border routers of those edge networks or anywhere else in the
Net.  Ideally, Ivip ITR functions are performed at border routers or
at transit routers close to the border routers of the sending hosts.
 But maybe it doesn't matter where the ITR is, as long as the total
path length is not much longer than would be the case without having
to pass through an ITR.  (It would be technically possible to put
Ivip's ITRs inside edge networks, or even do the encapsulation in
the sending host - but I don't see much point in either of these
approaches.  Encapsulation in the sending host would make a mess if
the host was behind NAT.)

I think part of the difficulty in this discussion is that my idea of
what LISP and Ivip (or any similar solution) can and should do is
rather different from some other people's ideas - or at least from
Dino's.  Maybe Dino and others see LISP or whatever as being used
primarily by existing AS-end users to handle whole subnets such as
/20, /24 etc. with each such subnet being tunnelled to one ETR.  I
think of this as a "Bring Your Own PI address space" plan.

I see LISP or Ivip as providing "effectively PI" addresses in much
smaller chunks than BGP can handle, including especially individual
IP addresses, to millions of customers who need multihoming and
perhaps portability.  The vast majority of those customers would
never get an ASN or want to know about BGP.  I see this as a way of
making much better use of scarce IPv4 space, which hopefully will
leave more space for new ISPs and for the larger AS-end-users who
would be best served with their own PI space and current BGP
approaches to multihoming and portability.

I discuss this in answer to Dino's questions below.

   - Robin

I have renamed this proposal Ivip (pr: eye-vip), though maybe "IVip"
or "IViP" would be better:

   Internet Vastly Improved Plumbing
   Internet Versatile redIrection of Packets
   Internet Versatile indirection Protocol
   Initiative to Virtualise IP addresses
     . . . etc.

This is a short acronym which is not particularly widely used, and a
quick search didn't reveal any use with this capitalisation.  "iViP"
won't do, because it looks too cute and commercial, like "iPod" -
and the Internet richly deserves its capital "I".

"Vastly improved Plumbing" is probably easiest way to understand
what I am trying to achieve.

I think the same thing can be achieved with LISP, but LISP requires
that the ITRs be either internal or border routers.  Ivip's ITRs can
be internal routers, border routers or transit routers.
(Theoretically, the Ivip ITR function could be performed in an
isolated router just for this purpose with a single connection to
any transit router.)

The primary benefit of Ivip over LISP (not counting Ivip's mobile
tunnel idea) is that it should be easy to incrementally deploy.
With LISP, any recipient host which uses a LISP EID as its address
will only be reachable from sending hosts located in edge networks
which have upgraded their border routers and/or internal routers to
perform the ITR function.  This is because LISP EIDs are IP
addresses which do not match a BGP-advertised prefix.

Ivip is a lot like LISP, but when a sending host sends a packet to
what I call an "Ivip-mapped IP address", the packet will be
delivered even if the sending host's edge network has not altered
its routers in any way.  The encapsulation will be performed by an
Ivip ITR (Ingress Tunnel Router) somewhere in the "core".  This is
most likely to be a transit router which also performs Ivip ITR
functions.

I think that there are different conceptions of what LISP can or
should do - for instance I think my understanding of LISP's power
and scope is more expansive than Dino's.  Not counting the mobile
tunnel idea, my conception of LISP's power and scope to provide
portable IP addresses, multihoming and maybe traffic engineering is
just as high as for Ivip.  I think Ivip's major advantage is that it
could be happily incrementally deployed - even as a paid for service
- whereas I think there is a major chicken-and-egg problem with
incrementally deploying LISP.

Below, I try to explain my conception of how LISP and Ivip would
best be used to achieve the major goals (multihoming, portability
and Traffic Engineering - TE) of those who use IP addresses, while
minimising the growth of the "global BGP routing table".

Let's say there was what I will call a "master subnet" which was
"LISP-mapped" or "Ivip-mapped": 22.22.0.0/16 .

The entire LISP or Ivip system would probably handle multiple such
"master subnets".  Most of these "master subnets" would hopefully be
bigger (shorter prefixes) than this for Ivip, because I intend Ivip
to minimise the number of new BGP advertisements while having as
much address space as possible to split up and assign to different
customers.

In both LISP and Ivip, any packet sent to an address in this range:

  22.22.0.0 to 22.22.255.255

will only be delivered to its proper destination if it is
encapsulated by an ITR, sent to the correct ETR and then
decapsulated and locally routed to the destination host.

For both LISP and Ivip, the ETR must:

1 - Have an IP address which can be reached directly via
    the current BGP routing system.

2 - Must be located in the edge network of the receiving host -
    either as a border router or an internal router.

3 - Must connect to a part of the internal network which is able
    to forward the decapsulated packet to the receiving host.

(It is also possible for the receiving host to do its own
decapsulation, although this probably achieves nothing useful other
than potential multihoming and TE, since the host needs a normal BPG
address to be able to do this.)

Now, for either LISP or Ivip I will consider different ways the
central database could direct packets addressed to this "master
subnet" to be handled by the ITR.

Mode 1 - Tunnel packets addressed to the entire subnet to a single
         ETR.

Mode 2 - Split the subnet into two or more smaller subnets, with
         packets addressed to each smaller subnet being tunnelled to
         different ETRs in the same edge network.

Mode 3 - Split the subnet into 2 to 10 smaller subnets, with packets
         addressed to each smaller subnet being tunnelled to ETRs in
         different edge networks.

Mode 4 - As for (3) but split the subnet into hundred or thousands
         of much smaller subnets, including individual IP addresses,
         and tunnel packets addressed to these subnets to ETRs in
         hundreds or thousands of different edge networks.

As I understand it, Modes 1 and 2 provide no substantial benefit in
terms of reducing the growth of the global BGP routing table.  There
may be some benefits in multihoming or portability of numbers
(making these mapped numbers usable no matter which ISP the ETR and
receiving hosts are located in).

With LISP, each initial "master subnet" does not produce any burden
on the global BGP routing table, whereas with Ivip, each one does
present a burden, since it is advertised in BGP.

With Ivip - and the proposal's viability rests on this being
possible - there are (ideally) thousands of Ivip ITRs in the "core"
of the Net, each advertising this "master subnet" or as many "master
subnets" as there are in the entire Ivip system.  No matter where a
sending host sends the packet from, if the packet is addressed to
one of these "master subnets" it will soon be forwarded to one of
these Ivip ITRs and tunnelled to the proper ETR.

I intend that the "master subnets" which are "Ivip-mapped" be
generally large, such as tens of thousands of IP addresses.  An
extreme case would to dedicate one or more /8s to Ivip.  (If this
was done, there could still be load balancing between multiple ITRs
in the same location, by each advertising a portion of this.)

I intend that each such "master subnet" be split into *many* smaller
sections, including single IP addresses, as for Mode 4 above.

Let's say the Internet has the following characteristics:

10,000 ISPs, with a total of 100,000 border routers, most of them
multihomed, advertising a total of 200,000 prefixes.  Most of these
prefixes are shorter than /24, because ISPs are generally interested
in large slabs of address space so they can connect lots of customers.

10,000 "AS-end-users", meaning companies, non-profit organisations,
universities, government bodies and a few keen individuals - not
ISPs.  These have 50,000 border routers, most of them multihomed,
and they advertise 100,000 prefixes.  Many of them advertise a
single /24 on one or the other of their links, even though they only
need one or a few IP addresses.

For simplicity I am discussing only IPv4 addresses and am ignoring
3G mobile carriers who probably want huge slabs of IP addresses for
their hundreds of millions of handsets.  (They may want IPv6 to fit
in with the Mobile Multimedia Subsystem.)

Let's say these ISPs and AS-end-users are quite happy with their
current situation, although their needs generally grow, which places
upwards pressure on the size (300,000) of the global BGP routing
table.  That growth is part of the problem, but the major problems
in IPv4 routing and addressing are:

1 - The shortage of fresh IPv4 addresses due to the need to
    assign them in largish chunks, including in the forlorn hope
    of maximising route aggregation.  Also due to the /24 limit
    on BGP advertisements which means 256 long subnets are
    assigned to many AS-end-users when they would be quite happy
    with a handful of addresses, if there was some other way
    of achieving multihoming, portability and maybe TE.

2 - The desire and need for new ISPs to connect their border routers
    and to gain new, large, slabs of IPv4 space which they will
    split up into still-largish subnets and advertise on BGP.  These
    new ISPs, over the next decade or two, number in the thousands
    or tens of thousands.

3 - The hundreds of thousands, millions and potentially tens of
    millions of large, medium and especially small end-users who
    want and need multihoming, ideally would like IP address
    portability, and who may want some TE capabilities.

    Without a new routing and addressing architecture, these will
    be either forced to become AS-end-users and further burden the
    global BGP system with routers and advertised prefixes, or will
    have to put up with single-point of failure links to an ISP,
    using non-portable IP addresses from that ISP.

I see LISP and Ivip as equally applicable to solving these problems
- with the small caveat that Ivip does add a little further to size
of the global BGP routing table for each "master subnet" the system
handles.

I intend that Ivip work with a relatively small number of "master
subnets" - a few to at most several hundred.  However, it is
possible that after 2011, it will make sense to grab sizable chunks
of IPv4 address space from whoever it is currently assigned to, when
that space is either not being used or is being used so lightly that
this cannot be justified while so many other ISPs or end-users need
the space and will be able (via LISP or Ivip) to use it very
efficiently.

"Efficiently", to me, means that the majority of addresses are used
by a host or a router.

I foresee the primary benefit of LISP or Ivip being the ability to
give an end-user a single IP address, or a small subnet such as four
to 16 addresses, which closely matches their immediate and
near-future needs, where those addresses will be:

a - Portable and usable via any ISP connection, as long as the ISP
    has an ETR (or as many ETRs are as needed to support such
    customers).

b - Multihomed to a certain extent with a single upstream link to
    the ISP, assuming the ISP is multihomed.  However this is not
    full multihoming.

c - Capable of being truly multihomed, if the end-user has two
    or more links to ISPs which have ETRs.  Then, the end-user
    (or some automated fault sensing centralised control system)
    will control the central LISP/Ivip database to tunnel packets
    to whichever ISP's ETRs it desires.

d - Capable of some degree of TE, such load balancing by having
    some of the end-user's IP addresses using one ISP's ETR and
    the others using the ETR of one or more other ISPs.

With a successful LISP system a single, unified Ivip system or even
multiple, independent Ivip systems (assuming the Ivip systems all
use relatively large "master subnets"), then provided all these
approaches divide their spaces down very finely, including to
individual addresses, this enables the Internet to cope with problem
3 above, very nicely, without any of those new end-users needing to
become Autonomous Systems, have BGP border routers, clutter the
global routing table with their /24s or waste precious IPv4 space
with those 256 long subnets when they probably only want one or a
handful of IP addresses.

(I am assuming widespread or ubiquitous NAT adoption for IPv4.
Maybe if IPv4 had always been flat-routed to individual IP address
granularity we could have used the space efficiently and avoided the
address shortage and therefore the evils of NAT, but I can't see how
the IPv4 Internet will ever be substantially free of it.)

Problem (2) is not altered directly by LISP or Ivip.  However, it is
made easier to solve if LISP or Ivip largely or completely handles
the vast number of end-users who need multihoming, portability etc.

As long as LISP or Ivip divide their subnets up very finely, then
this is the best possible contribution which can be made to solving
the address shortage problem (1).  Over time, I foresee Ivip or
something similar being used to efficiently use more and more of the
currently assigned address space.  All this reduces pressure on the
supply of fresh space.

In principle, if LISP or Ivip had been implemented from the
inception of the Internet, then the BGP routing system might only
cover a small subset of the available space.  The whole system could
have been engineered with a maximum number of advertised prefixes, a
maximum number of border routers - and therefore a maximum (and
hopefully high) number of ISPs, or at least ISP sites.  Then, most
of the rest of the address space could be handled with LISP or Ivip.

This raises difficult practical questions of how the ITR, for either
LISP or Ivip, efficiently handles hundreds of millions or even
billions of divisions of the address space for different tunnelling
treatment.

I am thinking of ASIC and RAM-based techniques optimised for such
lookups - which is one reason I am attracted to the idea of the ITR
function being performed by a smaller number of the most advanced
routers, such as transit routers (Ivip), rather than a larger number
of less advanced routers in edge networks (LISP).

If LISP was successful at individually mapping the IP addresses and
small subnets of millions of multihoming, portable IP address
desiring end-users, the requirements on each ITR's FIB would be
really onerous - and performing the functions in the router's CPU
would lead to really poor performance.

I hope the above description conveys my vision of Ivip (or LISP)
vastly improving the plumbing of the Internet.  Either should be
able to achieve, for end-users, the appearance of millions of
flexible "pipes", when in fact the BGP routing system only provides
a few hundred thousand physical pipes.

Christian Vogt wrote in message 01524 (with ViP changed to Ivip):

> is it correct to say that ViP anchors an access (or edge)
> network's prefix at the V-router somewhere within the DFZ?

If Ivip was used in modes (1) or (2) above, where an entire isolated
prefix of Ivip-mapped address space (for instance bounded by BGP
advertised prefixes above and below) had packets addressed to this
range tunnelled always to the one edge network, then the answer may
 be "yes".  However, like LISP, there are many such ITRs and the
destination address (EID for LISP) would be accessible by tunnelling
from any of those ITRs.

A LISP ITR which was also a multihomed border router would be in the
DFZ.

I will try to avoid the distracting term "V-router".  There would be
many Ivip ITRs and as I wrote above.  I think a single largish
"master subnet" like 22.22.0.0 to 22.22.255.255 should be split into
hundreds or thousands of separate mappings, to serve hundreds or
thousands of users.  Generally those users would connect by hundreds
or perhaps thousands of ISPs, but it would be technically possible
to have all those end-users accessing the Net via a single ISP.  At
least each one could move to another ISP which also had one or more
ETRs and take their IP address with them.

So generally I see each "master subnet" in LISP or Ivip being used
to direct packets to hundreds or thousands of separate edge networks.

Generally I think the best place for Ivip ITRs is at border routers
(single and multihomed) or in transit routers, so my initial mention
of ITRs in the DFZ was too loose, since single-homed border routers
are not in the DFZ.

Ivip ITRs could also be internal routers in the sending-host's edge
network.  They would grab the raw packets before they got to the
border router or out past the border router.  This could be a way of
removing some or all of the load of ITR work from the border
routers, which already have a huge number of prefixes in their FIBs.
(Assuming they are multihomed, with the full BGP set, plus all the
prefixes in the local network of telco carriers, ISPs and large
corporations etc.)

Whether a LISP or Ivip ITR uses push (has the complete database at
all times) or pull (has to query, learning not to query about
prefixes for which it recently got a "not mapped" response), the FIB
function has a lot of work to do and a large amount of data to
store.  My current feeling is that this can and should be done by a
smaller number of really advanced routers, such as the CRS-1, with
lots of memory and flexible dedicated CPUs (188 32 bit CPUs on a
single ASIC, the world's largest) - rather than on a larger number
of smaller ones.

> In this case, I would see a difference between Ivip and LISP
> in terms of responsibilities:
>
> - In Ivip, it is the responsibility of the destination access
>   network to set up (or subscribe to) the anchor router for its
>   prefix.
>
> - LISP relies on a router in (or at the border of) the source
>   access network to perform this functionality.

Ivip, in principle, could work with a single ITR (which I think is
what you mean by "anchor router") which is accessible via BGP.
However all traffic would have to be encapsulated by that single
router, so I suggest there be thousands of ITRs all over the world,
at border routers or close to border routers.

The way I am explaining Ivip is as a single, global, system with a
single centralised database which all ITRs have an up-to-date
version of.  This requires a push system, I guess, or some fancy
continuous "pull" system.  Ivip or LISP could work with a partial
database, with a "pull" system querying a central or distributed
system whenever a packet arrives with an unfamiliar IP address, but
that is very messy, has inherent delays, and still requires a fancy
FIB function and a lot of data storage.

There could be multiple Ivip systems all operating independently.

For instance, if I had an ASN and had a prefix assigned to me, I
could set up a bunch of ITRs linked to a central database.  Then, as
long as at least some ISPs had a suitable ETR (which only has to
strip the IP-in-IP header off a packet which is addressed to one if
its IP addresses) then I could rent out individual IP addresses or
subnets from my assignment, to any customer who was happy to use one
of the ETR capable ISPs.  (The ISP would need to configure their
routers to handle the IP addresses I assign to those end-users.)

This would be the RW Ivip network - so any customer of mine (someone
I rented one or more IP addresses to) moved to another ISP, they
would need to tell my system the IP address of the ETR in their new
ISP.  I think this means roughly what you wrote: "set up (or
subscribe to) the anchor router for its prefix.".

> This ViP concept reminds me of Mobile IP (v4 or v6), where
> a mobile host anchors its home network prefix with a home
> agent, the location of which is independent of the peer that
> the mobile host communicates with.  Both ViP and Mobile IP
> use tunneling between the anchor and the destination.

Yes, but Mobile IP, as I understand it and with the Ivip-mobile
(ViP-mobile) as I described in:

  http://www1.ietf.org/mail-archive/web/ram/current/msg01518.html

there is a two-way encrypted tunnel (or maybe two or more such
tunnels at the same time using different IP addresses, different
links via different ISPs etc.) between the mobile device and a
single "anchor router".

My Ivip-mobile idea is like this, assuming there are multiple hosts
H1 to H4 with ordinary BGP-routable IP addresses sending packets to
the one mobile device.

There are various ordinary Border Routers (BR) Transit Routers (TR)
shown for realism.

The ITRs are either border routers or transit routers.

     ITR1
H1---(BR)---------(TR)-\
     /                  \
H2--/                   (TR)-\
                        /     \
                       /       \   Translating
                      /         \  Tunnel Router
	     ITR2    /		 \					H3---(BR)----(TR)---/
(TTR)~~~~~(TR)~~~~(BR)~~~(NAT)~~(MH)
                 \               /
H4---(RR)-------(TR)------------/

H1 and H2 send raw packets to ITR1, which is the border router of
their edge network.  ITR1 tunnels the packets to the TTR using
IP-in-IP encapsulation.  LISP could do this too.

H3's and H4's packets leave their edge networks.  (This could not
happen with LISP, because they are not addressed to a prefix which
is advertised in BGP.)  These packets are forwarded by the BGP
routing system to the nearest router which advertises the prefix
they match.  For H3 and H4, this is the transit router ITR2.  ITR2
does the same as ITR1 - tunnels the packets to the TTR.

If this was Ivip-basic, both ITRs would tunnel the packets to the
ETR inside the edge network where the receiving host resides.

In principle, I guess the TTR could be a border or perhaps an
internal router, but it makes most sense if it is either a transit
router, or at least in the core of the Internet.  In practice, there
would be many TTRs, all over the world.  The Mobile Host (MH) would
somehow create an encrypted two-way tunnel to a TTR which was close
or closest to its current location.

That is a totally separate tunnel, shown as ~~~~~.  It is initiated
by the MH, as a VPN tunnel.  As such, it doesn't matter if the MH is
behind one or more NATs.  It would also be able to create this
tunnel to the chosen TTR if its current connection to the Net was
via Ivip-basic, but lets not try to think about that now!

With Ivip-basic, as per the diagram in my first message 01518, the
system only handles packets from left-to right.  Packets in the
return direction use ordinary BGP routing, assuming the host on the
left has an ordinary BGP-advertised IP address.

With this Ivip-mobile scenario, packets going back from the MH to
any of the H1 to H4 hosts, first travel in the encrypted VPN tunnel
to the TTR.  The TTR then extracts those packets and throws them
into the ordinary BGP routing system.  Since all hosts H1 to H4 have
  ordinary IP addresses, the packets travel by normal means to them.

The TTR needs to check the packets it extracts and forwards, for
instance to check the source address is as expected, to prevent
spoofing.

If there was an H5, which used an Ivip-basic-mapped IP address,
there are two ways the TTR could send packets to it.  Firstly, it
could place the packets into the ordinary BGP routing system, in
which case they would soon find themselves being encapsulated at an
ITR and tunnelled to H5's ETR.  Secondly, the TTR could perform the
ITR function itself: encapsulating the packet with IP-in-IP, and
then letting the main BGP routing system transport it to H5's ETR.

If there was an H6, which used Ivip-mobile, the same two approaches
could be used.  H6's ETR is actually a TTR, presumably different
from the TTR in the diagram above.  A TTR would also have to handle
packets between two mobile hosts which have tunnels to it.

I guess these mobile services are going to be a commercial service
since I can't imagine anyone running routers in the middle of the
Net like this for free.

I think a mobile host should be able to set up a second tunnel to a
different TTR, or perhaps a second tunnel via a different edge
network to the same TTR.  In the latter case, the TTR can decide
which tunnel to use, depending on some handshake or whatever to see
which one works best, or at all.

Ideally, if the one mobile host had two tunnels via two separate
ISP's networks (such as a 3G link and a WiFi link) to two TTRs, it
could switch to using the second TTR.  This would require that the
central database be changed so all the ITRs would tunnel (IP-in-IP)
packets intended for this mobile host to the second TTR rather than
the first.  This is just like taking a host from one ISP to another,
and changing the database to point to the new ISP's ETR.

>From the point of view of an ITR, it makes no difference whether the
ETR is an ordinary Ivip-basic ETR or a TTR.

> In fact, ViP is a proposal for network mobility.  It enables an
> access network to change ISPs (which is nothing else but a
> topological "movement") without losing reachability via the
> original prefix.

The explanations I have given were for single IP addresses - but the
same principles apply to an entire prefix.

Considering the whole "master subnet" or "master prefix"
22.22.0.0/16 which is one of the isolated prefixes handled by this
example Ivip system, I assume that prefixes above and below this are
not handled by Ivip.  So to use this prefix for Ivip, it has to be
advertised in BGP.  If the whole prefix was not split (Mode 1 above)
then it could be used as you describe, providing portability amongst
ISPs for the whole prefix.  This would save the end-user from having
to renumber when moving to another ISP.  However, it doesn't really
help reduce the size of the BGP routing table, since without LISP or
Ivip, this user would have got an ASN, been assigned the prefix as
PI space, and advertised it in BGP.

Also, with LISP or Ivip, if the end-user has two links to two ISPs
and can alter the mapping database rapidly when the currently used
ISP's link fails, then they have achieved multihoming.

LISP generally helps reduce the size of the global BGP routing
table, because no matter how small or large its "master prefixes",
and no matter whether the "master prefix" is split to be mapped to
multiple customers at multiple ETRs in multiple edge networks,
whatever it provides is without additional BGP advertisements.
(However this is on the assumption that devoting a prefix to LISP
doesn't punch a hole in a shorter prefix - longer subnet - which
causes it to be advertised as two prefixes rather than one.)

> Interesting...

Thanks!

Dino wrote, in message 01519:

>>      An Ivip-mapped address will be universally reachable as long
>>      as there is a single reachable Ivip ITR which can receive
>>      packets from the sending host and send encapsulated
>>      packets to the ETR for this address.
>
> When you say LISP-mapped or Ivip-mapped, it is not clear to me if
> you mean "map to" or "map from". Can you please clarify?

By "Ivip-mapped" I mean an IP address (or subnet/prefix) which is
not handled fully by the current BGP system, but causes packets
destined for this address or subnet/prefix to be tunnelled to an ETR
close to the receiving host.  So I mean the original address, as
used by the sending host (EID for LISP) is "mapped to" the IP
address of an ETR.  I haven't considered multiple ETRs, load
balancing etc. as you do in LISP, but that should work as for LISP.

I am trying to avoid "identifier", "RLOC" etc. terminology.

I would describe an IP address (or subnet/prefix) which is an EID
under LISP as "LISP-mapped".  Packets sent to this address or subnet
or prefix are "mapped" to be tunnelled to another IP address - the
RLOC - which is the address of the ETR.

An "Ivip-mapped" address is not directly reachable via the ordinary
BGP routing system.  However, a packet addressed to an "Ivip-mapped"
address will be forwarded by conventional BPG routers to the nearest
Ivip ITR.  If all is well, the ITR will tunnel it to the correct
ETR, just as with LISP.

>> 4 -  Point 3 has a profound effect on how the two proposals may
>>      be incrementally deployed.  With LISP, there is a serious
>>      and perhaps insurmountable barrier to anyone deciding to
>>      connect a host to a LISP-mapped address.  The first people
>>      to do this will find their addresses generally unreachable
>>      since virtually no edge networks will have upgraded any
>>      of their internal or border routers to perform LISP ITR
>>      functions.  Why should they?  It is a huge investment to
>>      enable communications with a handful of rebels who are
>>      voluntarily opting out of the BGP system (albeit for the
>>      benefit of humanity).
>
> A LISP site will have to use both PI and PA addresses for some
> time.  However, when it uses PI addresses that *will not* be in
> the core routing tables, other sites can reach them only if they
> are LISP enabled. Otherwise, the non-LISP enabled sites will reach
> the LISP site with PA addresses.
>
> So we can still reduce the size of the routing table and arguably
> more-specific injection from other PA blocks.

I understand from this that your transition mechanism involves each
receiving host (each host with a "LISP-mapped" IP address) having
two IP addresses at once: one conventional and one "LISP-mapped".  I
am not sure how this would be practical, unless host and operating
system software in the sending host could somehow choose between two
IP addresses returned by DNS, and use whichever one worked first.
If that could be done, the transition mechanisms would double the
number of IP addresses in use, at a time when they are in short supply.

Also, as long as the receiving host was reachable without LISP, I
don't see why the edge network of the sending host should invest in
one or more LISP ITRs.

I assume users cannot be expected to be involved in any of this.
For instance I assume it is not expected that people would be asked
to use wwwl.example.com if their ISP had LISP ITRs or otherwise to
use www.example.com.

>>      I can't imagine how LISP would ever get off the ground,
>>      since early adopters would have extremely patchy
>>      connectivity.  No-one would put a crucial service on a
>>      LISP-mapped address.  Since all crucial services would
>>      be available on ordinary BGP-routed addresses, why should
>>      edge networks spend money on a new or upgraded router?
>
> Because they want better control over their ingress traffic flows.
> They need the level of indirection to achieve this.

I think TE is a minor concern compared to the demand for multihoming
and portability - at least among the millions of smaller end-users I
am primarily thinking of.

I can't imagine anyone wanting to switch their server, site or
desktop computer to an IP address which had only marginal or
imperfect two-way communications with the rest of the Net in order
to achieve TE, portability, multihoming or even to be paid thousands
of dollars!

>>      ViP requires no changes in the edge network of the sender.
>>      It can be implemented with a single ITR on some BGP router
>>      somewhere in the world, and a single ETR in the edge
>>      network of the destination host.
>
> Can you explain how Ivip works with PI addresses?

I think your plans for using LISP - and no-doubt the plans of others
- differ considerably from mine.  I will try to state my guesses
about what you have in mind.  Please correct me if I am wrong.

I think you envisage LISP primarily serving the needs of
AS-end-users and perhaps ISPs.  I think this means current and
future AS-end-users, most of whom primarily want multihoming and
portability for their network.

I think you are primarily thinking of AS-end-users who want or need
thousands of IP addresses.

I foresee the most important users of LISP or Ivip as being partly
large end-users who may now have an AS or might otherwise be tempted
to get one in the future.  I figure virtually none of these people
or organisations have any enthusiasm for BGP.  They just want a
number of IP addresses connected to the Net, with multihoming via
two different links to two ISPs and/or with the ability to keep
their numbers so they don't have to renumber their networks when
they select another ISP.

The other users, probably the most important and numerous set, are
those who only need one or a few IP addresses.  I guess these
end-users are probably not too fussed about portability.  Their
networks are either small or have so few exposed IP addresses that
its not too much trouble to renumber a handful of routers or hosts.
 I figure they primarily want multihoming via two separate links, so
their businesses and organisations (their lives, with Second Life .
. . ) are not literally dangling from a single piece of fibre or copper.

I wonder about users who really want and need 256 or more IP
addresses.  Unless they are a little hosting company, I can't
imagine that many end-users really need 256 IP addresses at any one
site.  The most likely reason I guess end-users want to get an ASN
and 1024 IP addresses is so they can split them into four /24s and
advertise them at each of their branch offices.

It would be best if someone could provide real examples based on
experience rather than my guesses about what users want.  I am
thinking of people running small companies, schools, hospitals,
seriously Net-connected home offices etc.  Most of these end-users
want to run a mail server and perhaps reasonably high-volume web
servers from their physical sites.

I don't think LISP or Ivip helps much with new ISPs or the expansion
of current ISPs.  All ISPs, unless they are to become part of some
second-rate sub-caste of BGP-less ISPs, need an ASN, full BGP
expertise, multihomed border routers and their own slabs of address
space so they can do traditional BGP-based multihoming, offer
LISP/Ivip host connections etc.

I am hoping that LISP / Ivip or whatever will enable large areas of
address space to be very finely divided and used to meet the needs
of millions of companies, schools, SOHO people etc.  This will make
it unnecessary for most of them to get ASN numbers and to apply for
genuinely PI address space.

I think you envisage a "BYO PI space" model for LISP.

For both LISP and Ivip I foresee some larger entity, perhaps RIRs or
perhaps ISPs or commercial operators, providing stable, large,
ranges of address space for the system, and then having the system
divide it finely for millions, tens or even hundreds of millions of
end-users.

If there were plenty of ISPs with ETRs in place, there is nothing to
stop multiple ISPs or whoever else setting up their own Ivip systems
now.  All they need to do is have their own PI address space, set up
a database and a bunch of ITRs around the net - for instance at
various Internet peering exchanges or at the border routers of ISPs
around the world - and they can start renting out IP addresses and
subnets of addresses to anyone they like, provided those users
connect to the Net with an ISP who runs an ETR and is prepared to
route these packets to these customers.

>> 6 -  Because LISP needs to be a single system, it needs to be
>
> LISP needs to be a single system only when the entire network
> runs on PI addresses. That won't happen for a very long time.

What I meant to say is that I don't think that there could be
multiple LISP systems operating at once, because each system would
have to convince a huge number of ISPs all over the world to invest
in, or allow the installation of, an ITR which would handle the EID
to RLOC mapping of the IP addresses each system used as EIDs.

Maybe there could be a tech standard for ITRs and an edge network
could somehow let multiple LISP system operators control its
operations - but that sounds unlikely.

I could imagine multiple Ivip systems, because there is no need to
install ITRs in edge networks.  What would be required, as with
multiple LISP system, is a tech standard for the ETRs so all systems
could land their encapsulated packets in edge networks, without each
edge network needing to dedicate an ETR to each specific system.

If there were multiple Ivip systems, each system's ITRs would only
handle packets addressed to BGP advertised prefixes which were the
PI address space of that system's operators.

Since these ITRs will cost money, and do work for specific
end-users, I think there are arguments for multiple competing Ivip
systems to be created, charging the recipient host users for their
IP address space and according to traffic volumes.  Such a network
of ITRs could also be extended to do Ivip-mobile, which would
involve a lot more resources and definitely need to be a paid-for
service.

Multiple Ivip systems wouldn't need to know about each other, but it
would be best if they all operated on similar technical principles
and could all use the same ETRs in edge networks.

>> 7 -  One of the primary benefit of Ivip, together with providing
>>      reachability from the outset without requiring sending
>>      edge networks to do anything, is that there would be a
>>      smaller number of ITRs in the system.  These will tend to
>>      be bigger than with LISP and will have more intensive work
>>      to do.
>>
>>      I am thinking of direct RAM-based lookup approaches,
>>      involving two or so memory cycles, to speed this operation
>>      in hardware.
>>      Perhaps one or more models of current high-end router,
>>      such as the CRS-1, could perform these functions nicely,
>>      with an extensive firmware upgrade.
>>
>>
>> 8 -  With Ivip, packets to be encapsulated reach the edge of the
>>      BGP system or are forwarded within it, either to a single
>>      ITR (if the Ivip system only has one V-router) or to one
>>      of multiple ITR functions in separate V-routers all of
>>      which have the same IP address.
>
> Do you actually think a few ITRs is going to handle the load of
> the Internet?

To start with, strictly speaking, only one is needed to make the
system work.  To minimise the extra travel of packets, and for the
system to scale indefinitely, there would need to be hundred,
thousands and then tens of thousands of ITRs.

I figure this would be cheaper, more stable, and more scalable than
replacing all DFZ routers with souped-up versions to handle the
alternative: an ever growing BGP routing table.

I figure if there is a way that existing hardware, such as the 188
CPUs per SPP chip and massive high-speed RAM of the CRS-1's ingress
FIB could do the ITR functions, with little or no main CPU
involvement, it would be best to have a smaller number of these
around the Net, each directly "push" updated with the mapping
database second-by-second, than to get the same work done by much
slower software-intensive hacks in smaller routers in edge networks.
 Those more numerous smaller ITRs would also be more of a hassle to
keep fully updated.

>>      Ivip uses Anycast to provide multiple redundant paths
>>      within the BGP system for packets to find their way to
>>      an ITR.  Anycast is not normally used for TCP
>>      communications, but I am hoping it will be appropriate
>>      here, since the individual ITRs only encapsulate the
>>      packet and tunnel it to the ETR.
>
> I have actually tested LISP using anycast addresses and it has the
> same property. If ITRs have the following mapping cached:
>
> {0.0.0.0/0, > 1.1.1.1, 2.2.2.2} where 1.1.1.1 and 2.2.2.2 are
> anycast addresses, you can have various ITRs use the closest
> ETRs based on the above locator addresses.

My understanding of what you are doing here is a completely
different use of anycast than what I had in mind.  I was thinking of
anycast as a way of making multiple BGP routers accept (or rather
attract) the packets which were addressed to a prefix which needed
to be handled by an ITR.  So I was thinking of all those ITRs having
the same IP address.

Now I don't think this anycast has any purpose.  All that is
required is to make multiple ITRs advertise the same prefix.

Is there any precedent for two or more BGP routers advertising the
same prefix?  From what little I know of BGP, it should work fine -
but I would really appreciate a BGP expert's view of this.

I understand the purpose of your use of anycast is to deliver the
packets to a receiving host closest to the ITR.  Since the sending
host is presumably close to the ITR and the receiving host is surely
close to its ETR, this provides faster responses, less traffic
across the Net etc.  I hadn't thought of this.  I think it is a good
idea.

Since the ITR function of Ivip would be similar or identical to that
of LISP, the same thing could be done.

> In the spec we call these boxes "reencapsulating routers", where
> the anycast box decapsulates and then does a lookup on the inner
> DA where it has a different mapping (a list of locators where the
> site actually is) to reach the site's ETR.

Hmmm - this is a totally different purpose from what I guessed when
writing my response above.  I don't understood the need for multiple
encapsulations in LISP or Ivip.  Can you give an example of when
this would be helpful?

>> 9 -  LISP and what I will call "Ivip-basic" both have their ETRs
>>      in edge networks, or at the border router.  These ETRs must
>>      have an interface with an IP address which is reachable via
>>      the global BGP system.  These only handle packets one way -
>>      from the sender HA to the LISP/Ivip-mapped destination
>>      address of HB.
>>
>>      Packets in the return direction HA <- HB are sent normally,
>>      without relying on tunnelling, if the destination HA's
>>      address is not LISP/Ivip-mapped.  Otherwise, a similar
>>      process occurs with the packet being intercepted by an ITR
>>      and tunnelled to the ETR which handles HA's address.
>
> This can only work if HA is using a PA address.

I don't think it matters whether HA is using PI or PA addresses.  As
long as HA's address is part of a BGP advertised prefix which is not
handled by Ivip ITRs, then the the packets to HA will flow to it as
they do today, without using LISP or Ivip.

I wrote this point 9 as part of a sequence of differences between
LISP and Ivip, but this point only describes similarities and then a
separate mobile tunnelling idea.

>> Example of ViP-basic
>> --------------------
>>
>> ASCII Art only works with fixed width fonts:
>>
>>
>>   Edge Network A
>>                           [ITR]
>> HA---(IR)----(BR1NA)------(VR1)-----(TR2)--(TR4)   Edge Network B
>>                     \         \                \
>>                      \         \                \        [ETR]
>>                       TR1)----(VR2)---(TR3)---(BR1NB)---(IR)---HB
>>                          \             /
>>                           \           /
>>                          (TR5)----(TR6)
>>                                       \
>>                                        \           Edge Network C
>>                                         \ [ETR]
>>                                         (BR1NC)----HC
>>                                                \
>>                                                 ---HD
>
> I don't understand the benefit of reducing the number of ITRs but
> still maintaining an ETR in each site. You still have to manage
> the ETRs. So the gain is not that great.

I think the ETRs have a light workload and don't need any fancy
database.  Maybe existing routers can be programmed to look out for
an IP-in-IP packet addressed to one of their IP addresses and then
to simply pop off the header and treat the remaining packet as if it
had just arrived.  I recognise there may be more to do, perhaps
regarding ITRs trying to see if the ETR considers a destination host
reachable at present, and maybe things to do with transferring
hop-counts to the decapsulated packet.

I think ETRs are easy and could probably be generic.  I don't think
they need central management.

ETRs only need be installed at ISPs where customers are paying for
access and have chosen to use LISP/Ivip-mapped addresses.

Ivip requires a suitable number of high-performance ITRs out in the
Net in general, and LISP requires at least one ITR in every edge
network, ISP or AS-end-user, where there is a host which wants to
communicate with the host which is on a "LISP-mapped" IP address.

>> HA's address is 11.11.11.11, which is part of a prefix which is
>> advertised in BGP and which is not covered by Ivip mapping.
>>
>> HB's address is 22.22.0.1, which is part of 22.22.0.0/16, which
>> is also advertised in BGP and which is Ivip-mapped.  The other
>> hosts' addresses are:
>>
>>   HC = 22.22.4.1
>>   HD = 22.22.4.2
>
> If this is the example, why do you need ITRs or ETRs at all? If
> you have routeable addresses just move the packets as we do today.
>
> Dino

Because my intention is to split up the 65,536 addresses to be used
by customers far and wide.  In principle, each single IP address
could be mapped to a host in a different edge network.

I think your idea of how this stuff can best be used is rather
different from mine.

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