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
> 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 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.
Scott wrote:
> It's clear that pure endpoint-based multipathing, à la Shim6 REAP,
> cannot scale.
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.
> Putting path failure detection and recovery in ITRs instead of in
> the endpoints can greatly reduce the number of messages flying
> 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.
> 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.
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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
