I am replying to Ved's and Christian's comments in "Re: ViP:
Anycast ITRs in the DFZ & mobile tunnels", with "ViP"
changed to "Ivip" (eye-vip).

I apologise for the length again.  It would probably not be
so hard to describe Ivip to one person, face-to-face, with
conversation and hand-drawn diagrams.  Trying to do it for
a bunch of people via email takes more words.


VK> To me, the Ivip approach looks similar to the network mobility
VK> (nemo) support approach being discussed in the IETF nemo WG.
VK> In nemo, the mobile router's home agent advertises the mobile
VK> network prefix such that the packets sent by a correspondent node
VK> to an address belonging to the nemo prefix go to the home network
VK> of the mobile network, where the home agent tunnels them to the
VK> current location of the mobile router. The mobile router
VK> decapsulates and forwards the packets to the addressed node.

I threw this proposal together quickly without checking other
protocols - and I don't claim it is highly original.

There are two aspects to the proposal at present: "Ivip-basic"
and "Ivip-mobile".

Ivip-basic
----------

  H1---(ITR1)---\
      /          \
  H2-/            \
                  (ETR1)----RH
                  /
  H3---(ITR2)----/

       (ITR3)     (ETR2)


Sending hosts H1, H2 and H3 are assumed to have ordinary IP
addresses, reachable via BGP.  The ITR function is generally
performed in border routers or transit routers, but can be
performed in interior routers of the edge network.

Packets from the Receiving Host RH flow by ordinary BGP
routers back to the sending hosts.  If a sending host is also
using an Ivip-mapped IP address, then the same process occurs
in reverse, with the packet sent by RH finding their way to
the first ITR, probably at or near the border router of its
edge network, and being encapsulated and sent to the ETR for
the host on the left side.  None of this is shown in the
above diagram.

ETRs are provided by ISPs, or the AS-end-users who run the
edge networks.  They only serve receiving hosts in those
edge networks.

How does the edge network know that the decapsulated
packets emerging from the ETR must be sent to a particular
host in its network?  The ETR and the routers nearby
need to be configured to look out for this IP address,
or the Ivip-mapped subnet, and route it internally to the
receiving host.  With Ivip, these packets are addressed to a
prefix (a large subnet I call the "master-subnet") which is
advertised in BGP.  With LISP, they are not.

To support either LISP-mapped or Ivip-mapped IP addresses,
the edge network needs not only an ETR to decapsulate the
packets, but it needs a routing rule specific for that
IP address or subnet which directs packets addressed to that
address or subnet to wherever the particular host is located.

This is probably a non-trivial task for an edge network,
but the are being paid by their customer with the host which
uses LISP-mapped or Ivip-mapped addresses.


Assuming a single global Ivip system, the ITRs may be provided
by various operators, but work as a single system, without any
constraints on whose packets they will encapsulate.

What may be unique about Ivip is that these ITRs are numerous
and located (usually) at border or transit routers where any
sender's packets will eventually be sent to one.  What may
also be unique is the idea that all these ITRs advertise
the same set of prefixes: whatever "master prefixes" the Ivip
system handles.

Generally, these "master prefixes" are split into many smaller
sections, each with a different mapping to an ETR.  This works
fine down to individual IP addresses.  There needs to be a
single central system for controlling the mapping - and every
ITR has an up-to-date copy of this database.

Ivip-basic is a one-way, public, system.  Ideally it would be
provided for free, but there probably needs to be some fees
for running the ITRs and administering the database.  These
could be paid for by the Ivip "customers" - those individuals
and organisations etc. who pay for one or more IP addresses
in the system.

As shown above, the ETRs are in the edge network in which
RHs are located or connected to.

Each RH in this depiction has a single link to its ETR, but
an RH could easily have links to two ETRs, especially in two
edge networks, to achieve multihoming.


Ivip-mobile
-----------

Ivip-mobile is an extension of the above, but would probably
always be a commercial service.  There could be any number of
Ivip-mobile operators.  Each would have a set of special ETRs
called TTRs (Translating Tunnel Routers).  These TTRs are
in general either at border routers or more likely amongst
the transit routers.  TTRs could also be in edge networks.

  H1---(ITR1)---\
      /          \
  H2-/            \
                  (TTR1)~~~~~~~~MH
                  /            /
  H3---(ITR2)----/            /
                             /
       (ITR3)     (TTR2)~~~~/


The Mobile Host (MH) could be behind NAT and always
establishes an encrypted 2-way tunnel to at least one TTR.
(I am assuming an encrypted and compressed 2-way VPN-like
tunnel, but I guess it could also be done by simple two-way
IP-in-IP tunnelling.)

The Mobile Host may establish tunnels to multiple TTRs,
including using completely different links, such as ADSL and
GPRS radio.

The Ivip system maps the MH's IP address (or prefix) to one of
the TTRs, so all the encapsulated packets from the world's
ITRs arrive at that TTR.  Some central monitoring system
could detect that one TTR is dead, or that its link to the
MH is dead, and then the mapping could be changed to the
other active TTR.

To the Ivip system, which is really the ITRs and their
controlling database, there is probably no way of telling
whether the currently mapped-to IP address points to an ETR
which is for Ivip-basic (meaning the RH is in an edge network
and the ETR is a border or internal router of that edge
network, with packets flowing back independently of these
arrangements) or whether the mapped-to IP address points to
a TTR.

A TTR is simply an ETR which the MH tunnels to, and which
therefore also acts like the MH because this TTR is where
the MH's outgoing packets are first let loose on the Net.

With mobile-IPv6 (as I understand it), there is exactly one
router which the MH tunnels to - it is the router which runs
the LAN in which the MH's home address is located.

Mobile-IPv6 can also cause corresponding hosts (H1 to H3 etc.)
to send packets to and from the MH directly, rather than
using the home router.  This is more efficient, but requires
the corresponding host to have special mobile-IPv6
capabilities.

Ivip-mobile is very different from mobile-IPv6 in that the MH
can choose one or more TTRs to tunnel to.  Ideally it will
choose the ones which are closest to its current location.
Also, there is no "home IP address" on a LAN, as there must
be with mobile-IPv6.

As far as I know, mobile-IPv4:

  http://www.mip4.org

relies on a "home-router" and home IP address too.

Likewise, as far as I know, NEMO does as well:

  http://tools.ietf.org/html/rfc3963
  http://tools.ietf.org/wg/nemo/

Also, like LISP, Ivip works with single IP addresses or any
number of IP addresses.  I am not sure whether mobile-IPv6,
mobile-IPv4 support subnets, but I guess they could do it as
individual arrangements for multiple IP addresses.  NEMO
supports subnets.


The reason a figment of our imagination like Ivip can boldly
invoke a worldwide network of ITRs while mobile-IPv6/4
cannot is that now we are desperate.

If we don't do something on a grand scale such as this, we
will all be doomed to paying for endless upgrades to all the
Internet's transit and multihomed border routers as the BGP
routing table grows to 500,000, 1,000,000, 2,000,000 etc.

LISP boldly invokes at least one ITR in every edge network
which has a host which needs to communicate with a host or
network whose IP address or subnet is handled by LISP.  In
practice, for LISP-mapped IP addresses to be attractive to
anyone, this means most edge networks must have one or more
ITRs.

Ivip less boldly invokes ITR functions broadly distributed in
the border routers and transit routers.  I can get away
with this, as can the LISP authors, because we are desperate.

Both LISP and Ivip require the relatively modest ETRs to be
installed in the edge network of any host which has its
address or subnet handled by LISP or Ivip.

Ivip could also exist as multiple independent networks of
ITRs, each with its own "master-subnets" and its own central
database.

Since Ivip involves a bunch of souped-up routers at border
router and transit router locations, it is not much more of
a step to have some of these, or perhaps separate networks
of routers, performing TTR functions.  Each TTR system
could be entirely independent of other TTR systems, and of
the one or more ITR systems (provided the TTR did not also
implement ITR functions).  The multiple TTR systems could
compete and provide commercial services to the customers
who they provide Ivip-mapped address space for.

Please see my previous long message where I write about
my conception of Ivip or LISP, which I think is different of
Dino's "BYO address space" vision for LISP.

If there was a single Ivip system of ITRs, presumably the
system would not be allowed to fail, so any address space
it hands out via its mapping functions would be essentially
"Provider Independent".

If there were competing Ivip systems, then all of them,
apart from perhaps one "universal public" one, would be
dependent on some company, ISP etc. and be for-profit - so
the IP address still depends on that company.

However, in both cases, where the customer whose address is
mapped by these systems chooses to attach to the Net (their
choice of ISPs) is completely unrelated to the Ivip system(s).

Any TTR systems could be independent of the Ivip systems.

A customer could choose to use any number of competing TTR
systems.  They have nothing to do with IP addresses, since
their TTRs are only of value to the customer if the ITRs
tunnel packets to the TTRs, and since the customer pays for,
or has control of, the mapping of their IP address, the
customer only depends on the ITR system for the security of
"tenure" of this address - and not at all on any TTR systems
it uses.


Each TTR could also act as an ITR for that system's
"master-subnets".  If there was a single, global,
system of ITRs, it would be good if the privately run
TTRs also acted as ITRs within the global Ivip system.

Otherwise, packets would have to first find an ITR and be
tunnelled to the TTR when they are going to an Ivip-mobile
host.

For simplicity, the following assumes there is a single
set of "master-subnets" (AKA "master-prefixes") which are
handled by a single Ivip system which includes an Ivip-mobile
function as well.

It is likely that a router which performs TTR functions will
also act as an ITR.

  H1------(TR)------------(ETR1)------RH1
            \
  MH2~~~~~~(TTR1)~~~~~~~~MH1
            /  \
  H2----(ITR1)  \
         /      (TR)
  H3----/         \
                   \
  MH3~~~~~~~~~~~(TTR2)

H1 and H2 have ordinary BGP routed IP addresses.  Packets sent
from H1 to MH1 are received by TTR1 which acts like an ITR.
Ordinarily, an ITR encapsulates the packet and tunnels it to
the ETR to which the destination (MH1) IP address is mapped
to.  In this case, TTR1 is the destination ETR, so there is
no need to encapsulate the packet.  It is simply placed on
the VPN 2-way tunnel ~~~~~~~~ and sent to MH1.

Packets from MH1 to H1 follow the reverse path - they come
out of the VPN tunnel at TTR1 and are forwarded via normal
BGP routing back to H1.

The same would be true between H1 and MH2.

Packets from H2 to MH1 (or MH2) would be encapsulated by ITR1
and tunnelled (one way, IP-in-IP) to MH1's ETR, which is TTR1.
TTR1 decapsulates them and sends them on the VPN tunnel to
MH1.

Packets from MH1 to H2 pop out of the VPN tunnel at TTR1 and
use ordinary BGP forwarding to get to H2.

RH1 has an Ivip-mapped IP address.  It is not using
Ivip-mobile - just Ivip-basic.

In this diagram, the nearest ITR to H1 is TTR1.  When H1 sends
a packet to RH1, it is forwarded by the TR transit router to
TTR1, and encapsulated.  TTR1 sends the packet in a 1-way
IP-in-IP tunnel to ETR1 (at the border of, or within an edge
network), which forwards it within the edge network to RH1.

Packets from RH1 must be accepted by the border router of its
edge network (which could be ETR1 or some other router not
shown) and are sent via ordinary BGP forwarding to H1.

A packet from MH3 to MH1 goes via 2-way VPN tunnel to TTR2
where it is encapsulated and sent on a 1-way IP-in-IP tunnel
to MH1's ETR, which is TTR1.  This decapsulates it and sends
the packet along its 2-way VPN tunnel to MH1.  Packets going
from MH1 to MH2 follow exactly the opposite path, with a
1-way encapsulated IP-in-IP tunnel from TTR1 to TTR2.

Mobile-IPv6 doesn't assume anything about routers, except its
home router.  It doesn't assume anything about corresponding
hosts, since ordinary hosts can simply communicate with
the mobile host as if it was at its home location, with the
home router tunnelling to and from the mobile host, wherever
it is.

Ivip doesn't assume anything about corresponding hosts, or
the host whose IP address or subnet is mapped by Ivip.

Ivip does assume there is a system of ITRs - ideally all
around the Net at border routers and transit routers.

Ivip requires the receiving host have at least one ETR.  For
Ivip-basic, there will be one ETR in the edge network where
the receiving host is currently connected.  This mapping can
be switched to another ETR, for instance for multihoming.
There could also be load balancing between multiple ETRs, as
LISP proposes.


VK> Analogy:
VK> (1) Ivip routers are similar to the mobile network home agents,
VK>     except that the home agents are confined to home networks
VK>     where as Ivip routers may be distributed in the Internet.

Yes, but the TTRs are similar to the home-agent.  With
Ivip-mobile the mobile host's IP address doesn't have a home
anywhere.  Packets from ordinary IP addresses are tunnelled by
ITRs to the currently chosen ETR, and that ETR (in the case of
a mobile host) is a TTR which the mobile host has a tunnel to.

This means that wherever the mobile host is and wherever the
corresponding hosts are, assuming there are plenty of ITRs and
TTRs, the total path length will be the same as, or not much
longer, than without Ivip.

VK>     If we suppose that home agents can be distributed like Ivip
VK>     routers, then these two approaches are exactly the same.

In my perhaps faulty understanding of mobile-IPv4, mobile-IPv6
and NEMO, this could not occur, because the home-agent router
needs to be connected to an edge network whose border router
advertises the address range the router handles.  It can't
be moved somewhere else, assuming that router only handles a
part of the subnet its edge network advertises, because to do
so would create two or three BGP advertisements instead of
one.


VK> (2) Ivip's ETRs are similar to nemo mobile routers, which update
VK>     Ivip routers (home agent) with the tunnel-end addresses.

I read the first ten pages of NEMO's RFC3963.  NEMO extends
mobile-IPv6 with a "mobile router".  This is somewhat like a
mobile-IPv6 mobile node, except it is a router which has links
to the multiple mobile hosts.  Also, there is no "route
optimization" as in mobile-IPv6 where capable correspondent
nodes can send packets directly to and from whatever IP
address the mobile host (or NEMO mobile router) is currently
located at.  So with NEMO, all traffic to the multiple mobile
nodes goes through the fixed location (I assume) home agent
router, and then via a two-way tunnel to the mobile router
- which can flit from one IP address to another, taking its
flock of mobile nodes with it.

I don't think there is much resemblance between any of these
pre-existing mobile systems and either Ivip-basic or its
Ivip-mobile extension.

Ivip's notion of large numbers of public ITRs and TTRs (by
paid-for access I guess) with the mobile host choosing
which TTR to use at any time, does not seem to have a
parallel in these pre-existing mobile systems, which
assume a fixed home-agent router.

Ivip-mobile will only be possible because there will be
a global system of ITRs which tunnel packets to any
BGP-reachable IP address is currently selected to act as the
ETR for the mobile-host's Ivip-mapped IP address.

Without that global ITR system, steering packets anywhere on
the NET, the pre-existing technologies mobile-IPv4/6-NEMO
must rely on all packets going to a home-agent router, except
for mobile-IPv6 which can use "route-optimization" and set
up smart-enough correspondent nodes to send packets directly
to and from the mobile node.

LISP could just as easily be extended as I suggest with
Ivip-mobile.  Ivip is similar to or identical to LISP, or
at least some type of LISP, except that it should be easy to
incrementally deploy and except that it does require all its
"master-subnets" (hopefully few and large) to be advertised
in BGP.


VK> (3) In nemo, a bidirectional tunnel is set up to avoid packet
VK>     filtering at border routers. Whereas in Ivip, it is assumed
VK>     that the BRs forward packets with Ivip-mapped addresses.

In Ivip-basic, with the receiving host semi-permanently in an
edge network, I assume that the edge network's routers are
programmed to allow packets from its IP address to be sent to
the global BGP system.  If not, then the receiving host would
need to use Ivip-mobile with a TTR outside this edge network.

I tend to think of the TTR function being implemented within
routers which are already transit routers, or in routers
which are located at peering points and are primarily
connected to transit and border routers.  However a TTR could
be a border router or inside an edge network, as long as that
border router or edge network allowed egress of the outgoing
packets (which could have almost any source address) to the
BGP routing system.


VK> There are some well known problems associated with such anchor
VK> point-based approaches, such as increased packet delivery
VK> delay, non-optimal routing, tunnelling overhead, possibilities
VK> of single point of failure, etc. To avoid these problems,
VK> route optimization mechanisms are being investigated in the
VK> nemo WG. Shouldn't we look for the ID-loc split solutions that
VK> avoid such problems as much as possible?

Ivip-basic isn't at all like these pre-existing mobile
protocols.  The Ivip-mobile extension only loosely resembles
them, because there is no one fixed home agent.

Altogether, Ivip-basic and Ivip-mobile should enable packets
to flow without much extra distance or hops.  There is still
a tunnelling overhead, and perhaps problems with MTU limits.


Christian Vogt quoted Ved Kafle and responded:

VK> To me, the Ivip approach looks similar to the network mobility
VK> (nemo) support approach being discussed in the IETF nemo WG. ...
CV>
CV> Absolutely.  This is what I was saying.

I think Ivip is very different from NEMO etc.


VK> Analogy:
VK> (1) Ivip routers are similar to the mobile network home agents,
VK>     except that the home agents are confined to home networks
VK>     where as Ivip routers may be distributed in the Internet.
CV>
CV> Actually, Ivip routers are confined in the same way as home
CV> agents in that both can only support "home" prefixes that
CV> correspond to their topological location in the Internet.

As I explained above, and in a long message which started this
thread, this is not the case.  There are lots of TTRs to
choose from, so ideally the mobile node will choose one close
to it.  This is only possible because there is a global
network of ITRs, acting like a coordinated bunch of mirrors,
tunnelling all the mobile node's traffic to this TTR, another
TTR or wherever the mobile node (or some other control system)
tells the ITRs to tunnel the packets to.


CV> After all, the idea of Ivip routers is to have them advertise
CV> sub-prefixes from their ISP's global routing prefix so that
CV> the sub-prefixes can be aggregated with the global routing
CV> prefix and do not require a separate slot in the DFZ routing
CV> table.

An Ivip ITR is one of many which advertises one or more
"master prefixes".  Each ITR attracts packets addressed to
these prefixes and tunnels them off to potentially millions of
different ETRs.  A TTR acts like an ETR as far as the ITR
system is concerned.  Its just that a TTR is probably not in
an edge network - and it connects to the host which has the
Ivip-mapped IP address via a two-way tunnel.


VK> There are some well known problems associated with such anchor
VK> point-based approaches, such as increased packet delivery
VK> delay, non-optimal routing, tunnelling overhead, possibilities
VK> of single point of failure, etc. ...
CV>
CV> Right.  And things don't get better if we do the indirection
CV> for all hosts, not just mobile hosts or hosts moving with
CV> mobile networks.

Other than the central database, I don't think there is a
central point of failure for Ivip-basic or its Ivip-mobile
extension.  Assuming the mobile host has a BGP reachable
IP address, or is behind a NAT firewall which has such an
address, it can set up a two-way tunnel to one or more TTRs.
If one goes down, it can use another.  Ideally it would use
nearby ones.

Ivip-basic, like LISP, relies on the receiving host having a
connection to a particular ETR.  LISP, Ivip-basic and
Ivip-mobile all enable the receiving host to set up links
to multiple ETRs and then (directly, or by some automatic
system, since the receiving node could be out of contact
after the failure of its active link) the ITRs can all be
told to tunnel packets to whichever ETR is currently used.

This is genuine multihoming, including for Ivip-mobile - if
the two links to the two TTRs are by physically different
networks.


VK>                                    To avoid these problems,
VK> route optimization mechanisms are being investigated in the
VK> nemo WG. Shouldn't we look for the ID-loc split solutions that
VK> avoid such problems as much as possible?


CV> Without an intention to prefer either mechanism, I just want
CV> to note that the advantage of Ivip is a better transition path,
CV> whereas LISP performs better from the perspective of packet
CV> propagation latencies and fault tolerance.

Thanks for agreeing with what I think is the most important
difference - that Ivip looks like it would be easier to
introduce.


CV> As a matter of fact, LISP is nothing else but route
CV> optimization (in Mobile IPv6 terms) for Ivip.

LISP has the ITR function inside or at the border of the
edge network.  Ivip typically has the ITR function at the
border router or amongst the transit routers.

With LISP, if the ITR function is at the border router
or in an internal router which is on the shortest path
between the sending host and the border router, then the
total path likely to be the same as for a direct packet
(other than a potentially longer path in the destination
edge network if the ETR isn't exactly on the shortest
path to the receiving host).

With Ivip, the same is true if either of the following
typical conditions is true:

1 - The ITR function is at the border router of the
    sending edge network.

2 - The ITR function is in a transit router which is on
    the shortest path towards the destination edge
    network's border router.

So Ivip's total path length would only be longer than LISP's
if the ITR function was not in the sending edge network's
border router but in a transit router (or perhaps another
border router of another edge network) which is off the
shortest path to the destination network's border router.

If Ivip or some similar system is adopted, before long, any
ISP or AS-end-user network with any substance would want to
install the ITR function at its border routers and/or at
internal routers - to reduce the processing load on the
border routers.  They would want to do this so their outgoing
Ivip-mapped packets do not depend on anyone else's external
ITRs.

A fully hardware optimised ITR, with its big database and
need for constant updates from the central Ivip database,
could be quite expensive.  But it has to be provided either
by the edge network, or by some ISP or transit provider
the edge-network uses for its upstream links.

I am not sure how the economics would work best.  Maybe
for smaller ISPs and AS-end-user edge networks it would
be better to pay their upstream provider to handle the
ITR function.

Over time, as ITR-capable hardware costs reduced, more and
more smaller ISPs and AS-end-user networks would probably
find it better to run their own ITR rather than pay to use
their upstream provider's ITR.

I think only those smaller edge-networks would not run
ITRs in the long-run.  The most important thing is that Ivip
could start running with just a handful of ITRs somewhere in
the Net.  Ideally there would be multiple ITRs for each
country.

The only significant path-length increases with Ivip would
occur when the sending edge network is nowhere near an ITR.

This would occur in the early days of introduction.

But once Ivip became established and a significant amount
of traffic was reliant on ITRs, competition between
upstream providers would cause them to ensure there were
ITRs in upstream paths, rather than off to one side somewhere.

There are two other situations of practical interest, in
which Ivip would also produce no increase in total path
length.

Firstly, it is perfectly possible to install Ivip ITRs inside
edge networks.  Then, the situation would be identical to
LISP: assuming the ITR was on the path from the sending host
to the border router, there would be no extra path length.

Edge networks could install internal ITRs to take the load
off their border routers.  However, this would slightly add
to the traffic load inside the network, due to the IP-in-IP
overhead.

The second scenario is most likely to occur when the
destination edge networks are very close or their routers
are peers.

If the sending edge network has no ITR, the packets are
forwarded to the closest ITR, which is the border router of
the destination edge network.  This would work fine.  That
border router could encapsulate the packet and forward it
to the ETR inside the edge network.  There are a few
variations on this . . .

Firstly, maybe the border router is an ITR and the ETR is
a separate router inside the network - but the border router
has a route for the destination host's IP address already
programmed into it, as part of the whole destination edge
network being set up to send packets from the ETR to the
destination host.  Then, there would be no actual involvement
of Ivip, other than this border router was advertising the
whole "master-subnet" of which this destination IP address
was a part.  The fact that this border router received the
packet means that it forwards it towards the destination host
in its network.  The ETR wouldn't be involved and there would
be no encapsulation.

This would be the case if the border router's FIB applied the
local routing rules before the ITR function's rules - which
it should.

Secondly, if the border router's FIB applied the ITR
functions first, then it would tunnel the packet to the ETR
and all would be well.  (Unless the ETR was itself, in which
case it should just forward the packet on the internal
routing system.)

In either case, there would be no increase in path length -
above any detour inside the destination network to reach
the ETR.

If the sending host and receiving host are in the same edge
network, and if the whole edge network has its routers
programmed to handle the IP address of the receiving host,
then Ivip is not involved at all.

If the sending host was in some other part of the edge network
where the routers didn't know about how to route to the
receiving host, then the packet would be forwarded towards the
border router.  En-route, if it encountered an ITR, all would
be well.  If the edge network had no ITR, then the packet
would be forwarded out the border router and would find its
way to the nearest ITR.  Then it would be tunnelled back to
the same edge network's ETR.  This would definitely add to
the path length!


Here is a potential gotcha.

Lets say a host has two links to ETRs in two edge networks
A and B, and it is currently using the link to A.  This means
the global Ivip system's ITRs are tunnelling packets to A's
ETR.

Both edge networks must have their routing systems set up
to forward packets for the recipient host's Ivip-mapped
address (or subnet) to the link which leads to the receiving
host.  (For instance a router or a host computer with two
fibre links to two ISPs.)

Let's say there is a sending host in edge-network B.  That
sending host's packets will flow directly along the link from
B to the recipient host, even though the recipient host is
currently using the link to ISP for its connection to the Net.

For absolutely full connectivity, either:

1 - The receiving host needs to accept packets from both
    links at once.

or

2 - The network B needs to not forward the packets to the
    link to the recipient host until it somehow knows that
    the recipient host has switched to using network B's
    ETR.

Option 1 sounds best.


I apologise for the length of my messages.  I hope that
if you read them fully, you will understand Ivip and my
idea of what LISP can be used for in a way which is
independent of NEMO, mobile-IPv4/6 etc.   I think the
differences are more important than any similarities.

  - Robin




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