LISP has too many fundamental problems to be considered a
potentially practical solution. Some of these problems require
LISP is not perfect and still evolving but let me point out that every
design has fundamental problems. At this scale, it's very hard to be
perfect Robin. And as Noel has stated so many times, the hard
decisions must be made to incrementally deploy this. So things might
not look pretty on the surface, but jeez, you got to do what you got
to do. Else, this will all be academic.
We really want to solve this problem, sincerely. This is not lip
service, we are not just writing papers, we want to rev the Internet,
this is serious.
I want to address each of your 7 points below. I have cc'ed the [email protected]
mailing list so the folks who want to focus on details of LISP can
see this thread.
1 - Delays in delivering initial packets in a flow. This is either
due to sending the packets along the ALT network (which takes
time and involves sending substantial volumes of data packets
over the ALT network, rather than just mapping requests) or to
sending mapping requests only, and waiting for the ITR to get a
response before it attempts to send traffic packets.
We have a memory/bandwidth tradeoff. So we have to make a hard design
call. I'd rather have mappings cached and timed out so they can be
updated when they need to then to hold all the possible mappings for
the Internet in an ITR.
There is no such thing of a free lunch. You either store all possible
mappings or you fetch them when you need them.
According to: http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10
& 11 the experimental LISP ALT network's ITRs drop initial
packets and send brief map request messages. Even if we think
this delay doesn't matter, I am sure enough potential adopters
would - and therefore make it difficult or impossible for LISP or
any other such solution to be widely enough adopted to solve the
routing scaling problem.
Then why was/is ARP deployed in a 10^4 host-based bridged network with
basically the same properties. First packet loss is not persistent
when you look at all the traffic that originates from a source site to
another destination site.
The host vendors are probably thinking, if we do LISP in the host, you
could wait to send your TCP SYN before the mapping is available. Guess
what, you don't send that TCP SYN before you get the DNS Reply. ;-) I
wonder why? Well I'll spell it out. If a host needs an address to make
the connection, we can say it also needs a locator to make a connection.
The design choice of LISP *is to just change software in CPE devices*
to get the feature of decoupling rather than changing all the hosts at
a site. That's a huge deployment advantage. So these CPE devices get
packets before they have mappings. We don't even want to consider a
host to CPE router signaling protocol and all it's complexities to
solve this and to keep the architecture pure, we don't want to snoop
on DNS, SIP, or any other protocol that can give us a hint on where
the host is about to send a packet.
So the cost is *either* first packet loss or sending the packet on the
ALT using it as a request for a mapping.
2 - LISP-ALT's long-path problem
http://psg.com/lists/rrg/2008/msg01676.html
http://www.antd.nist.gov/~ksriram/strong_aggregation.png
[Fix? Another fundamental problem in the architecture. Could
be partially solved by more meshiness, but that would greatly
increase the complexity of the network and so raise more
scaling problems.]
Well this I believe is a duplicate of 1 above. So it's not really
*another* problem.
3 - Problems creating a highly aggregated ALT network in order to
speed the flow of packets up and down the hierarchy, while also
making the network robust against the failure of its routers and
tunnels. This has not been discussed much on the RRG, but it is
an obvious problem.
If we can do this with BGP, which we have decades of existence proof
why can't we do this with a tunnel topology 1) where a tunnel can be
rehomed much quicker and easily than physical links and boxes we have
to do with today, allowing aggregation to occur at the edges of the
ALT network, and 2) these tunnels stay up because there is robust
connectivity below the tunnel level to keep them up, hence there will
be less route-flaps for EID-prefixes.
I think it's the complete opposite of what you claim. I think BGP will
be more stable and scalable then the underlying BGP. Plus, what we
propose for the use-case of BGP uses quite a few features of it.
Recall this is eBGP over GRE.
We have an infrastructure where we can 1) ping to see liveness of
nodes on the ALT. We have traceroute to determine the path a Map-
Request takes on the ALT. We can ping/traceroute "underneath" so we
can see the diameter of the tunnel. Not only do we have a solution but
we use existing rudimentary tools for management.
And the address allocation hierarchy can map this logical ALT
topology. And if the Registries are involved in managing part of this
ALT network (which we hope and think they will), we can keep this
consistent relationship.
Do you realize the goodness of this? It's huge Robin.
There's more too, you then throw SIDR in the mix and we have secured
the ALT, we have secured mappings, we created a PKI for routing use.
In fact, the first SIDR deployment could happen on the ALT to be
verified/experimented before it goes on the underlying BGP.
And note, that the infrastructure will/does carry exactly 2 address-
families. So we can do 6-to-6-over-4 with this approach. That means we
can get two site to be *IPv6-only* and be able to talk to each other.
If you are a IPv6-only site now or a dual-stack site, you could talk
to the new IPv6 Google services. I think this is a pretty huge feature.
This is clean and architecturally pure, no double NATs, no CGNS, and
no applications breaking.
4 - LISP-ALT's Aggregation implies provider dependence.
This is Christian Vogt's critique:
http://psg.com/lists/rrg/2008/msg00259.html
Not true. Aggregation here is for the EID-prefix. Service providers do
not carry EID-prefixes in their cores so you don't depend on them. The
decoupling of the address creates this. The dependence is now on the
ALT. And if your site resides in a specific region of the world, you
get your EID-prefixes from that registry. So readdressing your domain
would only occur if you moved it from one region to another (let's
leave mobile ASes out of this for now).
5 - Path MTU Discovery problems. Despite Fred Templin, myself and
others discussing the inherent PMTUD problems in any map-encap
proposal, there has been nothing from the LISP team to indicate
they have a solution. They seem to think there is no problem.
In section 5.4 of draft-farinacci-lisp-11.txt we describe two proposed
solutions, one is stateless, and the other is stateful. The stateful
creates no new table data structures but requires storing an addition
2-bytes of effective-MTU state per mapping.
6 - Lack of business case for LISP's Proxy Tunnel Routers:
http://psg.com/lists/rrg/2008/msg02021.html
You cannot fault a technical design for a business case. A PTR is
solving a technical problem. And if we want to *truly* keep lots of PI
type routes out of the core *and* avoid NAT solutions which are just
way too high in opex, the PTR is the only solution we have to turn to.
And on the contrary, I do believe service providers, interconnect
providers, registries, third-parties and even governments will provide
PTR services. Will they make a ton of money out of it, well that
remains to be seen.
7 - The scaling problems of potentially thousands of ITRs each
probing reachability to one ETR, and likewise, one ITR probing
reachability to many ETRs - this is one view of the "Locator Path
Liveness Problem" of draft-meyer-loc-id-implications-00.
http://www.irtf.org/pipermail/rrg/2009-January/000809.html
That is not in the LISP design. Everyone just thinks it is. ;-)
Dave and Darrel's draft is providing a warning about how bad probing
can be. They do not take a position whether it should go into any
proposal. They are just saying, beware of the Frankenstein that may
result and can be an interpretation to not do probing at all.
Like I mentioned in a previous RRG email message, one has to ask the
question if an ITR *should* switch from one RLOC to another when there
*may* be a path failure *somewhere in the middle of the network*.
Please note my very fine qualifications.
If we want to solve this problem, we could do this today by having a
host switch it's TCP connection to another A record. This doesn't
happen today because people deal with packet loss, since it doesn't
last long *and* rerouting actually works quite well.
Van Jacobson always made this comment and I'll never forget it, "The
fact that the Internet drops packets is it's greatest feature".
What else can either an xTR or TCP host do when sending ICMP
Unreachables are off by default in most modern routers, or they are
filtered by firewalls, and route aggregation hides failures close to
packet sources.
Unless these concerns are adequately addressed, claiming that LISP
is an appropriate solution to the problems discussed at the IAB's
October 2006 Routing and Addressing Workshop is nothing more than
a proof by an emphatic assertion.
I agree entirely.
I believe the LISP team could have made much better use of the RRG -
by participating fully in the debates resulting from these critiques.
We were asked to do research in RRG. That was a reasonable request. So
the research stuff in LISP has been and will continue to be presented
in RRG.
As for the engineering issues, the real details and bits and bytes, we
want a forum to discuss and work out issues in an open forum. I've
been going to IETF for 20 years now, that forum is called a working
group.
The working group doesn't have to standardize what it is working on.
And the charter and the numerous requests we have made requests *for
an experimental working group*.
Experiments won't help solve most of these problems. I am not
against experimentation and I think it is great that there is a LISP
experimental network.
However, I would never have taken a proposal to the point of writing
code, running a network and inviting others to write compatible
implementations when the proposal had so many fundamental problems.
There is constant implementation feedback back into the design.
Experienced engineers know how this cycle works. You start with
something you think can hold together, you try things out, you refine,
you revisit design, you go forward with implementation. That's the
process of *detailed* engineering.
For the old timers, that was the difference between TCP/IP and OSI.
Sorry for the long email,
Dino
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
