Folks,
Let me try my explaining my issue with Locator Liveness
from a slightly different perspective.
Summary
-------
These are the differences the proposals I've seen to date
induce on the Internet (detail below):
(i). Complexity of finding a usable <src,dest> address
pair goes from today's O(M) to O(N^2),
(ii). New failure modes are introduced if the searching
(or something) isn't done,
(iii). In addition, GSE doesn't have the option of
searching, due to knowledge asymmetry inherent in
the design. As a result, GSE has no apparent way
to fix the locator liveness problem, even with
brute force searching. Again, this is because the
GSE rewriting element doesn't have the
information necessary to do the searching.
More detail
----------
Today, a host generally queries the DNS and gets one or
more A records for the destination in response. When it
tries say, to put up a TCP connection to the remote side,
it either connects (gets a SYN-ACK) or it times out. It
can go ahead and try other addresses if it likes, since
it can see them (to the extent that the DNS works, etc).
The host uses the source address of the interface used
send the packet to the destination (at least that's how
the unix boxes I have [Ubuntu, MAC OS, Fedora, and
Gentoo] have behave, with a few twists around multiple
default routes and different interface speeds).
As a result, finding a working destination is today at
worst linear in the number of A records for the
destination; call it O(M) for M possible destinations. Of
course, if the host participates in routing (say the
site's IGP), then that is a different case which we can
discuss if you like. However, I want to stay on the
simple case for now.
So let's take a look at how the various loc/id separation
schemes find working destinations (or <src,dest> pairs if
that turns out to be necessary), and why they are
different than what we see today.
(i). In the the SHIM6 or HIP version IPv6 world,
I have multiple addresses per interface. Those
addresses may be PA or PI addresses. In any
event, I need to figure out which combinations
work, since if I latch on one that doesn't work
I'll wind up with a persistent/non-recoverable
failure. Where I have N source addresses and M
destination addresses, this is easily shown to be
O(N*M). So If N > M, just call it O(N^2).
This situation is different than what we
experience in today's Internet architecture,
because today hosts only have to search O(M)
destinations, not the cross product. Further, if
you don't do the search and you latch on a
non-working pair, you have a persistent
failure. That is different from today, and is
precisely the case that the REAP protocol was
designed to prevent.
(ii). In the GSE world, you can't do the O(M*N) search
because you don't know M. So you can fail (hard)
by having the rewriting element choose the wrong
source RG. All the host can do here is time
out. So this is O(M) from the hosts perspective,
but the might not find a working pair even though
one exists. So now you have a new failure
mode. Of course, the rewriting element might try
to do the searching, but without snooping on the
data path it cant tell which ones work and which
ones don't. So GSE can't really fix this problem
(at least not as Mike defined it).
On the complexity side, in general, network-based
schemes have the following complexity: If I have
N IDs (or whatever you want to call them, ULD,
HIT, EID, ID) and M source locators (in this
case, the network element is M-way
multihomed). The network element could be
rewriting element (such as GSE, in which case the
host specifies N), or it could be map-n-encap
(like Ivip, eFIT, LISP, ...), but that doesn't
matter for this argument.
Simply, if L_i is the number of locators for ID
N_i, then the complexity is bounded by O(P),
where
P = M*sum(L_i), i = 0...N-1
Back to the GSE case: The difference here is that
the complexity is increased from O(M) to O(P)
(again, you could say O(N^2) if you like), and
because of the asymmetric distribution of
knowledge defined in the "GSE-classic spec", the
host has half the knowledge and the rewriting
element has the other half, and this introduces
an a new (and persistent) failure mode.
(iii). In a map-and-encap scheme, where the host has no
visibility into the locator space (contrast GSE,
where the host sees the "destination locator"),
it can still try the O(M) destination addresses
(EIDs in this case), but in this case each of the
M destination EIDs could map to a different
locator. So the mapping agent might in the worst
case try O(P) <source,dest> locator pairs.
So like in the GSE case, if the mapping agent
latches on to one that doesn't work, you have a
persistent failure. Map-and-encap schemes don't
share the asymmetry problem with GSE, so the
mapping agent here can in theory solve this
problem since it has the requisite information.
Hopefully this gives some idea of the differences between
today's behavior and the behavior of the different
proposals, as well as where my concern lies. There are
more cases (and different security properties,
etc). However, I hope this is enough to start a more
detailed discussion.
Hope this helps.
Dave
signature.asc
Description: Digital signature
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
