Subject: [rrg] No liveness requirement in the ID/Loc Split concept

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 15 Jan 2009 10:42:12 -0800

Coworkers,

In response to the draft-meyer-loc-id-implications-00.txt I-D, I sent
private observations to the authors of that I-D together with a small
subset of interested parties. Somebody (Dave Meyer??) requested that
this private dialog should rather be moved to this email list for
participation of the larger community. Towards that end, I would like to
summarize the view from my knothole about the RLOC/EID split issue to
this list:

1) Routing systems using RLOCs naturally reference RLOCs for routing
aggregation. Every network system that I have worked with except for IP
(e.g., OSI, SNA, BSC, XNS, etc.) instead does routing on EIDs. These
latter systems do not recognize RLOCs.

2) In historic IP, IP addresses became semantically overloaded with both
RLOC and EID semantics. I surmise that the IP designers originally
thought they were doing EIDs like every other protocol then existing but
they actually invented RLOCs, without recognizing the implications of
the difference. Regardless, both semantic concepts became located within
the IP layer. In practice this meant that EIDs were not operative for IP
routing at all: EID is usually NULL for traditional IP routing; EID
primarily semantically appears for protocols operating above the IP
layer, causing cross-layer protocol dependencies in such systems. 

3) IP combined the RLOC and EID concepts into a single system that
lacked the ability to disambiguate between them. Consequently, some
systems (e.g., routing) presumed that they were talking with an RLOC and
other systems presumed that they were talking with an EID. The IP system
didn't provide any assurance that either reference or presumption was
actually the case (e.g., anycast). This became known as the "IP identity
problem", which is a fundamental and pervasive security flaw within IP
systems that is solved by the RLOC/EID split concept (e.g., HIP). Within
historic IP we either locate something without identifying it or else we
identify it without locating it. This provides the foundation for
"Rekhter's Law". That we cannot authoritatively know which reference is
operative provides the foundation for the "IP identity problem".

4) Multihoming is an EID concept. EID-based routing systems naturally
and transparently support multihoming. RLOC-based routing systems cannot
naturally support multihoming because they lack the information to be
able to naturally recognize the occurrence of multihoming.

5) In RLOC/EID separation systems like HIP, the RLOC and EID each occurs
on different layers of the protocol stack. Therefore, attempting to get
IP routing, which works on the IP layer (i.e., RLOC layer) to be aware
of multi-homing, which occurs on the EID layer (i.e., the session layer
within HIP), is a protocol layer violation.

6) IP routing is not equipped to natively be able to do multi-homing and
attempts to enhance it to do so further complicate the RLOC-EID
confusion and actively harm the Internet. Attempting to enhance routers
to handle multi-homing inherently violates the loc/ID split concept. The
desired distinction between EID and RLOC needlessly becomes replaced by
mutual dependencies between the two concepts. By adding EID dependencies
to RLOC, there cannot be "better aggregation in the RLOC space" because
no RLOC space can exist. Rather, that space potentially becomes EID*RLOC
space, which probably represents significantly worse aggregation than
the historic IP routing system.

7) The RLOC-EID split concept therefore means that multihoming needs to
be solved at a layer above the IP layer that can naturally see the EID.
Attempts to simultaneously achieve a Loc/Id split and have routing doing
multihoming are vectors that internally war with each other. The net
result are the types of problems identified in
draft-meyer-loc-id-implications-00.txt, problems that cannot occur if
the RLOC-EID distinction is done properly (i.e., RLOC and EID at
different layers of the protocol stack).

8) When RLOC-EID is done properly (e.g., like HIP where each concept
appears on a different layer of the protocol stack), there is no
liveness problem (nor can there be one). Rather, the "liveness problem"
described in draft-meyer-loc-id-implications-00.txt is a generic problem
of map-and-encaps systems, not of RLOC-EID. The title and text of
draft-meyer-loc-id-implications-00.txt is therefore inappropriately
scoped as being caused by RLOC-EID when it is rather a common attribute
of map-and-encaps. Note that LISP is a map-and-encaps system.

9) It is useful to discuss both map-and-encaps and multihoming from the
insights contained within Fred Templin's VET/RANGER/SEAL I-D trilogy.
This trilogy discusses scalable map-and-encaps systems and indicates how
to resolve the liveness problem for those systems. It also provides an
important context for describing multihoming because it identifies the
recursive nature of the "enterprise" concept. Without leveraging the
insights of this trilogy, multihoming may appear to mean different
things in different contexts: Autonomous systems can be multihomed.
Mobile platforms can be multihomed. Hosts can be multihomed. Etc. These
different environments are recursive instances to different sized
"enterprise" entities. Failing to realize this complicates discussions
about multi-homing.

--Eric

_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 15 Jan 2009 10:48:15 -0800

Eric,

>-----Original Message-----
>From: Fleischman, Eric
>Sent: Thursday, January 15, 2009 10:42 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [rrg] No liveness requirement in the ID/Loc Split concept
>
>Coworkers,
>

FWIW, this is completely consistent with the latest version of
VET that I have just posted:

http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-27.txt

but I think you will find that the new version is much more
comprehensive in terms of PI addressing, site multi-homing,
ingress filtering, routing scaling suppression, MTU robustness,
locator liveness determination, etc. etc.)

Thanks - Fred
[email-masked]

---

From: David Meyer <[email-masked]>
Date: Thu, 15 Jan 2009 10:56:00 -0800

> subset of interested parties. Somebody (Dave Meyer??) requested that

	Guilty :-)

	But seriously, thanks Eric.

	Dave

---

From: Scott Brim <[email-masked]>
Date: Thu, 15 Jan 2009 14:32:05 -0500

> within HIP), is a protocol layer violation.

Nor should it.  IP routing itself should deal with finding paths to
destinations (and forwarding should deal with forwarding individual
packets).  Determining that that sending to either of two apparently
different destinations gets the packet to the same higher layer entity
has nothing to do with routing.

> 6) IP routing is not equipped to natively be able to do multi-homing
> and attempts to enhance it to do so further complicate the RLOC-EID
> confusion and actively harm the Internet. Attempting to enhance
> routers to handle multi-homing inherently violates the loc/ID split
> concept. The desired distinction between EID and RLOC needlessly
> becomes replaced by mutual dependencies between the two concepts. By
> adding EID dependencies to RLOC, there cannot be "better aggregation
> in the RLOC space" because no RLOC space can exist. Rather, that
> space potentially becomes EID*RLOC space, which probably represents
> significantly worse aggregation than the historic IP routing system.

However, map-and-encap adds a new control and OAM relationship,
between the "funnel" ingress and egress points.  These are beyond the
knowledge or control of endpoints, yet they promise to deliver
packets, therefore they have a responsibility to find and use viable
paths.  They are not _just_ routers at this point.  They are also
endpoints in their own right.  They are doing more than discovering
paths and forwarding packets.  Since _sites_ have multiple ingress
points, multihoming applies here too, they have a responsibility to
handle multihoming just as endpoint stacks do.  Even if the session
endpoints are already taking care of multihoming themselves, they are
only capable of doing so over the choices that are given to them by
the "funnel" endpoints.  I don't think you can say the endpoints
should take care of everything -- they can't.  Anymore than the
endpoints take care of everything when running over any underlying
switched network.

But the "funnel" endpoints do not know enough about what the session
endpoints want or need -- is the endpoint already taking care of
multipathing?  Does it require session continuity and thus must have
backup paths lined up at all times?  And so on.  Therefore the funnel
endpoints overdo their responsibility.

It's clear that pure endpoint-based multipathing, à la Shim6 REAP,
cannot scale.  Putting path failure detection and recovery in ITRs
instead of in the endpoints can greatly reduce the number of messages
flying around, but a simple approach there doesn't scale either, and
without information they don't have much choice.  

One thing we could do is to couple them.  The endpoint could
periodically tell "the network" what it needs, so the network only
needs to do just enough.  

Another thing we can do is cut back on our requirements, at least for
a while.

> of map-and-encaps. Note that LISP is a map-and-encaps system.

I don't see it.  HIP properly removes dependency on location-based
names from identification functions, but it does nothing to solve the
multipath problem.  You still need to find viable paths, ascertain
that multiple locators refer to the same entity (difficult when one or
both are moving -- rendezvous servers may be required, tsk), detect
path failure and switch to another one.  The same is true for Shim6,
or Trilogy multipathing ... or anything where you have the chance of
using multiple paths.  A simple host in a simple PI-based AS can't,
and therefore doesn't have a problem to solve.  Adding HIP in fact
makes the problem possible.

> "enterprise" entities. Failing to realize this complicates discussions

I'm partway through them.  Sorry for not being able to respond about
this part.

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Jan 2009 08:36:16 +1300

Eric,

(cross-post to lisp dropped)

On 2009-01-16 07:42, Fleischman, Eric wrote:
...
> of map-and-encaps. Note that LISP is a map-and-encaps system.

I've said from day one that LISP's use of the term 'EID' is incorrect,
and it should be replaced by something like 'local locator' or
'level 0 locator' or some such. So a more positive spin on your
subject line is 'Liveness requirement in multi-locator architectures'.
Which is of course something that has been discovered many times
and is very widely implemented in robust distributed systems.

Another positive spin is 'Mapping requirement in ID/Loc split concept'.

   Brian

---

From: Scott Brim <[email-masked]>
Date: Thu, 15 Jan 2009 14:46:15 -0500

Excerpts from Brian E Carpenter on Fri, Jan 16, 2009 08:36:16AM +1300:
> On 2009-01-16 07:42, Fleischman, Eric wrote: ...
> > 8) When RLOC-EID is done properly (e.g., like HIP where each
> > concept appears on a different layer of the protocol stack), there
> > is no liveness problem (nor can there be one). Rather, the
> > "liveness problem" described in
> > draft-meyer-loc-id-implications-00.txt is a generic problem of
> > map-and-encaps systems, not of RLOC-EID. The title and text of
> > draft-meyer-loc-id-implications-00.txt is therefore
> > inappropriately scoped as being caused by RLOC-EID when it is
> > rather a common attribute of map-and-encaps. Note that LISP is a
> > map-and-encaps system.
> 
> I've said from day one that LISP's use of the term 'EID' is
> incorrect, and it should be replaced by something like 'local
> locator' or 'level 0 locator' or some such. So a more positive spin
> on your subject line is 'Liveness requirement in multi-locator
> architectures'.  Which is of course something that has been
> discovered many times and is very widely implemented in robust
> distributed systems.

Identifier/locator separation makes the problem possible, and it can
make it possible at any point in the network.  At any point we can
have a separation of 

  - a name the packets are trying to get to
  - a name for a point in the network via which they can be delivered

and the problems are similar in all cases, whether you use
"identifier" and "locator" to name the things or not.

> Another positive spin is 'Mapping requirement in ID/Loc split

Mapping is just part of the problem.  You can map to all possible
paths, but you have to establish a session in the face of all the
choices, and track and recover from failures.

Scott

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 15 Jan 2009 22:37:16 +0200

> It's clear that pure endpoint-based multipathing, a la Shim6 REAP,  
> cannot scale.

Would you please be more specific.  It is not at all clear to me.   
AFAIK, SCTP is doing essentially the same thing.  (I can see the  
signalling load there, causing potential packet storms; is that the  
"scalability" problem you are referring to?)

> Putting path failure detection and recovery in ITRs instead of in  
> the endpoints can greatly reduce the number of messages flying  
> around, but a simple approach there doesn't scale either, and  

AFAICS, the fundamental problem here is that the network today (BGP)  
cannot detect failures at the desired speed, leading to the situation  
where the hosts (or your funnel points) need to overcome the deficiency.

>> is no liveness problem (nor can there be one).
>
> names from identification functions, but it does nothing to solve  
> the multipath problem.  You still need to find viable paths,  
> ascertain that multiple locators refer to the same entity (difficult  
> when one or both are moving -- rendezvous servers may be required,  
> tsk), detect path failure and switch to another one.

I mostly agree.  In the HIP WG, years ago the decision was to leave  
the problem of path failure detection to the SHIM6 WG, with the  
intention to integrate REAP to HIP.  However, with HIP (even LHIP)  
verifying that the locators refer to the same entity is relatively  
easy, as long as at least one of the parties retains at least one  
stable locator.  Rendezvous servers are a nice way to introduce stable  
locator to an otherwise dynamic system...  And then, under those  
assumptions, finding paths and switching over is relatively easy.   
Works very well in practise.  We've multiple times tested it with both  
proxies and individual hosts, using 2-3 different radio interfaces at  
each mobile host/proxy, and moving at typical vehicle speeds in  
difficult terrain.  But I digress.

--Pekka

---

From: Scott Brim <[email-masked]>
Date: Thu, 15 Jan 2009 16:10:38 -0500

> "scalability" problem you are referring to?)

I should have done the math first but ... Let's assume,
conservatively, on the order of ten billion communicating endpoint
pairs and 2 locators per endpoint.  How often do you test locator
pairs that you are not using?  Let's be very conservative and assume
once per minute (endpoints can get away with this low level).  Even
so, that's an extra 2^10 packets per minute across the core ... when
things are going perfectly, just for steady state maintenance.  I
can't characterize what percentage of traffic that is, because, for
example, there may be plenty of HTTP sessions that are idle but being
kept open.  We could reduce that maintenance overhead.  Then we add in
what happens when there is a network problem.  I suspect that because
there are active sessions and data is flowing, you would try all
alternative paths at once, with fast probes and duplicate data
packets.  I really don't know what would happen, but I'm awed at the
thought.

> cannot detect failures at the desired speed, leading to the
> situation  where the hosts (or your funnel points) need to overcome
> the deficiency.

Suppose I am at locators A and B, you are talking to me at locator A
and A becomes unreachable.  Regardless of how fast routing detects
that, you (an endpoint) are going to need to detect it yourself,
verify that B is reachable, and switch to B, so you need your own
fault detection and recovery protocol.

>> ascertain that multiple locators refer to the same entity
>> (difficult when one or both are moving -- rendezvous servers may be
>> required, tsk), detect path failure and switch to another one.
>
> stable locator.  Rendezvous servers are a nice way to introduce
> stable locator to an otherwise dynamic system...  And then, under
> those assumptions, finding paths and switching over is relatively
> easy.  Works very well in practise.  We've multiple times tested it
> with both proxies and individual hosts, using 2-3 different radio
> interfaces at each mobile host/proxy, and moving at typical vehicle
> speeds in difficult terrain.  But I digress.

That's not a digression, that's real evidence :-).  My concern is not
that "finding paths and switching over is relatively easy", but what
happens when everyone does it.

Scott

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 15 Jan 2009 22:19:28 +0100

Scott Brim escribió:
> pairs that you are not using?  
what do you mean by a "locator pairs that you are not using"?

You mean a locator pair that is not the one that is the current locator 
pair, or do you mean the current locator pair, but that you don't have 
data packets to send in this moment?
regards, marcelo

> Let's be very conservative and assume
> things are going perfectly, just for steady state maintenance.

>   I

---

From: Scott Brim <[email-masked]>
Date: Thu, 15 Jan 2009 16:24:31 -0500

> data packets to send in this moment?

If one end has locators A and B, and the other end has C and D ...
then unless you are multipathing you will use a single pair, e.g. A-C,
while A-D and B-C are not being used, just checked for liveness in
case a need arises.

---

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 15 Jan 2009 13:35:54 -0800

Scott,

>>Eric Fleischman wrote:
>> described in draft-meyer-loc-id-implications-00.txt is a generic 
>> problem of map-and-encaps systems, not of RLOC-EID. The title and
text 
>> of draft-meyer-loc-id-implications-00.txt is therefore
inappropriately 
>> scoped as being caused by RLOC-EID when it is rather a common 
>> attribute of map-and-encaps. Note that LISP is a map-and-encaps
system.

>Scott Brim wrote:
>the multipath problem.  You still need to find viable paths, ascertain 
path 
>failure and switch to another one.  The same is true for Shim6, or 
>Trilogy multipathing ... or anything where you have the chance of using

>multiple paths.  A simple host in a simple PI-based AS can't, and
therefore 
>doesn't have a problem to solve.  Adding HIP in fact makes the problem
possible.

Thank you for sharing your insights. Concerning this specific insight, I
believe that what RLOC-EID split systems like HIP primarily do is to
disambiguate the semantic confusion so that routing (i.e., RLOC) issues
are local to the IP layer and EID concepts are local to the HIP session
layer. 

I fully concur with you that the IP (routing) layer is responsible to
find viable paths between RLOCs, which can be challenging in the highly
mobile environments in which I primarily focus. 

Our research has demonstrated that a key benefit of HIP in highly mobile
environments is that the HIP session layer provides a buffer that
shields the transport and application layers from network effects such
as multihoming and mobility. Our experiments have demonstrated session
persistence even within highly unstable network environments caused by
substantial MANET mobility. We have demonstrated that HIP session layers
simply need not care about underlying IP layer issues such as whether
the underlying network is using IPv4 or IPv6. We've demonstrated HIP
sessions that cleanly and transparently persisted through real-time
underlying network swaps from IPv4 to IPv6 and back.

In our private discussions I observed that because routing can only see
RLOCs and therefore can't discern the existence of multihoming,
multihoming needs to be handled at a layer that has visibility into EIDs
where it can be seen. I received strong push-back on that private list
to my suggestion that multihoming should be an optional service function
of the session layer, perhaps using an optional timer value in the
session layer to substitute a different RLOC source ID value in the
underlying local IP layer if the current RLOC hasn't received any
traffic in a given time quantum. 

I am comfortable receiving push-back on my suggestion in the previous
paragraph because this idea of mine hasn't been adequately examined.
What I am not comfortable with is any approach that attempts to solve
multi-homing at the IP layer because I believe that routing should
solely aggregate and forward packets based on RLOCs -- anything else
needlessly complicates routing and harms Internet performance and
scaling. Therefore, multihoming is not a function of the IP layer. I
realize that this belief of mine conflicts with IETF work and thought
(e.g., the domain discussed by draft-meyer-loc-id-implications-00.txt),
but this nevertheless is how I see things.

--Eric

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 15 Jan 2009 22:37:29 +0100

> while A-D and B-C are not being used, just checked for liveness in
That's not how REAP works
REAP does not probes for liveness of unused paths AFAICT

Regards, marcelo

---

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 15 Jan 2009 15:46:03 -0800

>From: Fleischman, Eric 
>In our private discussions I observed that because routing can 
>only see RLOCs and therefore can't discern the existence of 
>multihoming, multihoming needs to be handled at a layer that has 
>visibility into EIDs where it can be seen. I received strong push-back 
>on that private list to my suggestion that multihoming should be an 
>optional service function of the session layer, perhaps using an 
>optional timer value in the session layer to substitute a different 
>RLOC source ID value in the underlying local IP layer if the current 
>RLOC hasn't received any traffic in a given time quantum. 

>but this nevertheless is how I see things.

Scott Brim and I had a private discussion concerning the impact of HIP
on RLOC-EID liveness. As part of that discussion, he recommended that I
forward to the list my following additional opinion concerning the above
first paragraph:

My suggestion in my first paragraph above was a possible extension to
HIP or other EID-RLOC separation systems. HIP doesn't do liveness now in
the base HIP specs. However, the HIP community is currently considering
eventually possibly adopting two different liveness alternatives: using
SIP's ICE for NAT traversal and SHIM6's REAP for multihoming -- I
believe these proposed approaches are unacceptably resource consumptive,
which is why I made the above suggestion. Regardless, HIP doesn't do
either today but it currently does protect the transport layer and above
from having to care about multihoming or network issues. Specifically,
the session doesn't care what RLOC is used to support that session at
the IP layer -- any packet duplications will be handled at the transport
or application layer. It's simply not a problem.

My previous suggestion (above) was how to respond to the liveness
problem for HIP should the current network path fail in multihoming
environments. Currently, if the routing layer doesn't have a live path
to an RLOC supporting that EID, then the session is not receiving
packets. If the network layer is not aware of an alternative RLOC (which
is what I expect to be the norm), then it can't use that alternative
remote multihomed RLOC unless it is redirected to it by a mechanism that
is unrelated to routing tables (i.e., routers should only deal with
RLOCs). My original paragraph above suggested a way to alert the remote
peer to the existence of another RLOC supporting that EID so that it
could try that alternative path. This presumes a non-symmetric routing
blockage (i.e., not due to a blockage affecting all of a peer's
transmissions regardless). 

Regardless, I believe that the id/loc split concept presumes that the
session layer needs to handle multihoming and the IP layer need to
handle routing between RLOCs. The two concepts (RLOC, EID) need to
remain separated without becoming confused by needless dependencies.
_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: Robin Whittle <[email-masked]>
Date: Fri, 16 Jan 2009 14:52:02 +1100

I am responding to Eric Fleishman and Scott Brim, regarding:

  http://tools.ietf.org/html/draft-meyer-loc-id-implications-00

My previous RRG message explains the following taxonomy:

  Elimination (genuine, host-based, ID/Loc split):
     HIP, Six/One, SHIM6 and ILNP.

  Separation (network based ITRs and ETRs using a mapping system -
  with no host involvement in multihoming.  Arguably not a true
  ID/Loc Split arrangement):
     Map-Encap:
       LISP, APT, TRRP and Ivip using encapsulation.

     Map-Forward:
       Ivip's two Forwarding modes. (Modified IP headers
       and DFZ routers.)

     Map-Rewrite:
       Six/One Router.

Eric wrote:

> the "liveness problem" described in
> draft-meyer-loc-id-implications-00.txt is a generic problem

I disagree that the objectionable scaling problems which are the main
concern in the "locator liveness problem" are inherent in map-encap
systems.

Ivip in both its map-encap and its (modified IP header) forwarding
modes does not have this scaling problem because the ITRs are not
responsible for deciding which LOC address to tunnel the traffic
packets to.

In Ivip, the mapping information for each micronet (roughly
equivalent to a LISP EID prefix) consists of a single LOC address -
the address of the ETR by which the destination network can currently
be reached.

The destination multihomed end-user network is responsible for
probing the reachability of their network via its two or more ETRs -
and for changing the mapping of their micronets in real-time so that
when the current ETR becomes unreachable, all ITRs will use another
ETR address instead.

Therefore, there is no scaling problem with thousands or hundreds of
thousands or whatever ITRs all simultaneously trying to test
reachability to the two or ETRs of this destination multihomed
end-user network.

The formal definition of the problem from the I-D is:

     Given a set of source locators and a set of destination
     locators, can bidirectional connectivity be determined between
     the <source locator,destination locator> address pairs?

(Strictly speaking, it is not necessarily to determine a single path
 for bidirectional communication.  For instance, it is OK for packets
 to flow like this, if the connectivity permits:

  CEA -> ITR1 -> ETR3 -> CEB
  CEA <- ETR2 <- ITR4 <- CEB )

Here is a diagram relevant to Core-Edge Separation schemes, depicting
two hosts, in separate multihomed end-user networks NA and NB, each
with two upstream ISPs:

                        ~~~~~~~~~~~
   NA           ISP1   ~           ~   ISP3         NB
            PE1      BR1---     ---BR3     PE3
 ........  /    ITR1   ~\         /~   ITR3   \  ........
 .      . /     ETR1   ~ \       / ~   ETR3    \ .      .
 . HA---CEA            ~    DFZ    ~           CEB---HB .
 .      . \            ~ /       \ ~           / .      .
 ........  \   ISP2    ~/         \~   ISP4   /  ........
            PE2      BR2---     ---BR4      PE4
               ITR2    ~           ~   ITR4
               ETR2     ~~~~~~~~~~~    ETR4

(Fig 1)

If the packet flow is NA --> NB, then CEA could send the packet to
either upstream ISP.  So for LISP etc. (not Ivip) either of both ITR1
and ITR2 need to continually check reachability to both ETR3 and ETR4
- or rather that firstly whether ETR3 and ETR4 can be reached and
secondly, that each ETR can reach the Customer Edge router of NB: CEB.

In practice, if CEA only sends packets addressed to HB out via the
ISP1 link then ITR2 never sees them, does not get mapping for HB's
EID prefix, and does not have to keep checking reachability to the
ETR addresses (LOCs) listed in the mapping.

Ivip's real-time mapping gives all the involved ITRs (ITR1 and/or
ITR2 in the above HA -> HB example) the information they need to be
able to tunnel packets to an ETR by which HB can be reached.  So Ivip
ITRs do no reachability checking.

Neither LISP etc. nor Ivip solve the problem of telling CEA which
upstream link to send packets from.  The CEA router needs to do its
own reachability testing to its two upstream ISPs, and ideally would
also determine whether each ISP was functioning in terms of
forwarding packets correctly to all destinations.

The real "locator liveness" problem is a scaling problem.  It occurs
in LISP etc. when there are host in thousands or hundreds of
thousands of networks such as NA sending packets to NB.  Since each
such sending host network will have one, two or more ITRs, the
scaling problem is the vast number of ITRs which need to be
continually probing reachability to both ETR3 and ETR4.

Ivip has no such problem because, irrespective of how many ITRs are
sending packets to the micronet in which HB is located, the
reachability testing is done by whatever purpose-built system the NB
uses.  The most likely arrangement is for NB to contract the services
of a company which specialises in this reachability testing, from
multiple locations in the DFZ.  The typical arrangement would be for
NB to give that company the credentials it needs to change the
mapping of NB's micronets in order to spread incoming load over NB's
upstream links, and to restore connectivity if an ISP or a link to
and ISP, fails.  This way, the mapping is changed quickly without any
reliance on NB's network being reachable at all.

Of course, NB could use one or more such reachability testing
companies and use the results in its own servers to make the final
mapping decisions.  Placing those servers in its own network would be
tricky, since they need to function reliably at times of partial
network failure.  It would be better to rely on the distributed,
highly robust, purpose built system of a company which specialises in
reachability testing.

> It's clear that pure endpoint-based multipathing, à la Shim6 REAP,

Yes, for SHIM6, HIP, ILNP or whatever elimination scheme it is, the
problem is likely to be worse than depicted above using ITRs and ETRs.

With the above example, there could be 100 hosts in NA sending
packets to one or more hosts in NB, and there would be no extra
burden of probing traffic etc. - since the same number of ITRs (ITR1
and/or ITR2) are involved.

With HIP, or any other host-based Elimination scheme, the diagram
looks like this:

                        ~~~~~~~~~~~
   NA           ISP1   ~           ~   ISP3         NB
            PE1      BR1---     ---BR3     PE3
 ........  /           ~\         /~          \  ........
 .      . /            ~ \       / ~           \ .      .
 . HA---CEA            ~    DFZ    ~           CEB---HB .
 .      . \            ~ /       \ ~           / .      .
 ........  \   ISP2    ~/         \~   ISP4   /  ........
            PE2      BR2---     ---BR4      PE4
                       ~           ~
                        ~~~~~~~~~~~

  HA's addresses:                         HB's addresses:

    wwww (from ISP1)                      yyyy (from ISP3)
    xxxx (from ISP2)                      zzzz (from ISP4)

(Fig 2)

HA needs to probe reachability in these paths:

   wwww -> yyyy (presumably, with confirmation packets coming
                 back via xxxx <- yyyy)
   wwww -> zzzz (ditto wwww <- zzzz)

   xxxx -> yyyy (ditto xxxx <- yyyy)
   xxxx -> zzzz (ditto xxxx <- zzzz)

This exact situation is comparable to that depicted in Fig 1.  The
number of probes is roughly the same and the burden they place on the
DFZ is about the same.  The probing is more thorough, because it
tests complete host-to-host reachability, thereby picking up any
problems between each host and its CE router - which are not picked
up in LISP etc. or typically by the systems which would be used by Ivip.

There are at least two reasons why the "locator liveness" problem is
worse for HIP, ILNP etc. (any host-based Elimination scheme) compared
to LISP etc. (any Separation scheme in which the mapping lists
multiple ETR addresses and requires each ITR to test reachability to
them):

1 - The probe traffic goes all the way to and from the hosts.
    This is a major burden on any host on an expensive, slow and/or
    congested link - as is typically the case with any physically
    mobile device using one or more wireless links.

2 - There is an additional scaling factor in comparison to Fig 1
    when there are multiple hosts in each end-user network.

    For LISP etc. those additional hosts do not cause any burden
    on the probing effort.

    For HIP etc. the load multiplied directly with the number of
    hosts.

Point 1 is one of the aspects of my critique:

  Fundamental objections to a host-based scalable routing solution
  http://www.irtf.org/pipermail/rrg/2008-November/000233.html

and HIP, with all its cryptography, host-to-host handshaking before
any user traffic can proceed etc. exemplifies my other critiques
about delaying communications and burdening all hosts with excessive
protocol and computational complexity.

Point 2, I think, is what Scott is referring to regarding REAP not
scaling.

> around,

Yes, as illustrated above, for multiple sending hosts in one end-user
network.

> but a simple approach there doesn't scale either,

Yes: LISP, APT, TRRP and Six/One Router - or any scheme where the
ITRs are given non-real-time mapping and so need to continually find
out for themselves, independently, which ETRs are reachable.

> and without information they don't have much choice.

Ivip gives the ITRs the information in real-time - so the ITR has no
such choices to make.

> periodically tell "the network" what it needs, so the network only

More and more complexity . . .

> Another thing we can do is cut back on our requirements, at least
> for a while.

I don't see how, other than by making LISP into something less robust
than it is intended to be.  No-one would want to invest in a system
which provides multihoming "sometimes".

Scott also criticised HIP's reliance on rendezvous servers to cope
with the messy situation of both hosts trying to retain consistent
communications at the HIT level when their underlying LOC addresses
are in flux, as will often be the case in the future as more and more
mobile devices are used.

> rendezvous servers may be required, tsk

"tsk" seems rather reserved.  How about:

  More and more complexity and management traffic . . . Arrrggg!!!!

 - Robin