Short version: Responding to Dino's reply to my critiques of LISP.
The LISP team should do detailed critiques of APT
and Ivip as part of convincing IETF folks of the
merits of LISP-ALT.
Will it be possible to do firmware upgrades so all
DFZ routers ca. 2014 will handle packets with
modified IPv4 and IPv6 headers, to forward the
packets the ISP network of the ETR, without
encapsulation, its overheads and PMTUD problems?
If so, then maybe we could go straight to this
approach and forget about encapsulation and all
its complexities.
Hi Dino,
Thanks for your reply:
> Sorry for the long email,
We are attempting to re-engineer one of humanity's most excellent and
important communication networks. Long detailed messages are often
appropriate.
>> 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.
I wasn't suggesting a proposal should be perfect. I pointed out
problems which I consider to be fundamental - not "on the surface".
Some can be fixed by adding new design elements, but I think the
others are only fixable by radically altering the current design.
I stand corrected about LISP's approach to PMTUD - the latest draft
does include an outline of a workable solution.
> 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 have always known you and the other LISP folks really care for the
Net and are working hard to devise the best possible improvements.
Despite it only having had broad-based commercial, political and
inter-personal impact in the last 15 years, the Internet is a
momentous development in human relations. We all want to see changes
which will enable it to remain technically viable - and hopefully
elegant - for the long-term future.
However, I think you jumped straight into some seemingly attractive
approaches which turn out to have problems I consider to be serious.
It seems that you and the APT folks thought for a few moments about a
real-time mapping system and figured it was out of the question. I
think it is not at all out of the question - and when you have
real-time mapping distribution, you can do some elegant and valuable
things:
1 - Separate out reachability testing and ETR choice mechanisms and
let (actually require) the end-user networks to do it themselves
- or pay someone else to do it for them.
2 - Enable the end-user networks to do real-time incoming TE control.
3 - Send the mapping update stream to local query servers, so there
is reliable and very fast responses to mapping requests - and
therefore no need to delay or drop initial packets.
4 - Charge a small fee per update to pay for most of the mapping
distribution system.
5 - Provide much better support for the TTR approach to mobility:
http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf
I think the ALT system is a lot niftier than CONS, but still, you are
delaying initial packets (APT and Ivip are not), forcing every ITR to
do its own reachability testing and monolithically integrating those
testing and ETR choice mechanisms into the core-edge separation
scheme itself.
I don't think we should be rushed into thinking we can't possibly
have local full-database query servers in ISPs and larger end-user
networks, or that it is impossible to push the mapping to them in a
few seconds (real-time). One advantage of the real-time approach
over LISP-ALT, APT's approach or the TRRP DNS-like global query
server approach is that it is streamlined and includes multiple
mapping changes (dozens or perhaps a hundred IPv4 mapping changes) in
a single packet.
> 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.
OK, we are also transmitting to [email protected] and
[email protected] .
>> 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.
That is the dichotomy between LISP-CONS/ALT and LISP-NERD. However
there is another approach (APT and Ivip): full push to local query
servers.
RAM and hard drive space is very cheap. The query servers don't need
to be Cisco-style routers. They can be COTS or high-reliability
rack-mount PCs - with gigabytes of RAM and terabytes of hard disk
storage.
In Ivip, IPv4 mapping consists of 12 bytes:
Start of the micronet (32 bits)
Length of the micronet (32 bits, but typically 16 or less)
ETR address (32 bits)
So if you have a COTS server with 16GB of RAM (this will no-doubt be
the common amount of RAM in PCs by the time a core-edge separation
scheme is deployed) then you can easily dedicate 12GB for mapping
information. That is a billion micronets (more or less, depending on
the storage format), which will do the trick for many years to come.
(IPv6 mapping is more bloated, but there is a longer time-frame for
implementing millions or billions of IPv6 micronets - time for RAM to
get cheaper still).
I think you - and the designers of APT and TRRP - have been somewhat
captive to established ways of thinking about how to solve a
"routing" problem: with more "routing" style structures. This means
more routers, more messages and replies zipping around the world etc.
It doesn't have to be like this.
I need to do more work on the fast-push system of Ivip - but you are
welcome to critique it in its current form:
http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00
If your design choice with LISP is optimal, or the only one you think
is available, then you should be able to point out why it is
impractical or undesirable to use an approach such as Ivip's:
real-time fast push on a global basis to local query servers, with
local pull from there to ITRs, followed by pushed updates from the
query server to the ITRs if a micronet's mapping changes within the
caching time of the mapping reply.
Likewise, you presumably have a critique about the practicality or
desirability of APT: slow push to local query servers (Default
Mappers) in each ISP, local pull from ITRs querying the Default
Mappers, local push of mapping updates from DMs to those ITRs which
need it (I think) and (again, my recollection) the Default Mappers,
rather than the ITRs, doing reachability testing and choosing which
ITR address an ITR uses.
The Net will soon be delivering gigabytes of video data to homes, in
near-real-time, for a few dollars. Generally, a packet can be sent
from any host to any other host in 0.2 seconds or less.
In this scenario, why do you think global push to local query servers
- including high-speed, real-time push - is impractical or
undesirable?
>> 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.
This doesn't apply to small end-user networks. If there are to be
hundreds of millions of these sites, meaning hundreds of millions of
EIDs or (Ivip) micronets - then these are mainly going to be small
"sites", such as home offices, or more likely mobile devices. The
initial packet delay will directly impact usability, since there may
only be one human user at each such "site".
If many small "sites" use a common ITRs in a large ISP, there will be
less trouble with this, since it will be more common for one site to
generate a packet to some EID/micronet which the ITR has mapping
from, due to another "site" sending a packet there too. However, the
frequent delay of initial packets (actually, it seems you are
planning to drop all initial packets) will still be a problem.
If LISP is not meant to scale to a hundred million or a billion or
whatever "sites", then by whatever same smaller target number of
EIDs, micronets or whatever, this would make alternative approaches
such as Ivip or APT even more immune from whatever scalability
critiques you might make of them.
> 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.
On IPv4, with most human-used hosts behind NAT, you can't put a LISP
ITR in the sending host, because the map reply won't come back to the
host.
In a scenario in which LISP is widely - ubiquitously - deployed, many
DNS servers are going to be on EID space. This means the ITR will
often need to do a mapping lookup before it can send a DNS request.
The sending host will be on EID space and so the DNS server's ITR
will need to do a mapping lookup too before it can send the return
packet. This will suck to a high degree in the current arrangement
where the DNS server sends a single packet. The ITR of the DNS
server will drop that packet and send a mapping request for the
original sending host's EID. Then, after a while, the sending host
will realise it got no DNS response. If it sends the same request to
the same DNS server, it will get a response back quickly, since now,
the DNS server's ITR has the sending host's mapping in its cache.
But what if the sending hosts does it it might reasonably do: send
the request to a different DNS server? Then the same pattern as
above occurs again.
> 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.
So you are proposing that every DNS reply also include full LISP
mapping for every one or more EIDs of the one or more IP addresses
returned? I doubt if that will always fit in one packet.
> 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.
OK . . . LISP mutates again! I have been following LISP intently
since about March 2007 and I don't recall any mention of changes to
hosts or to CPE - by which I guess you mean DSL, cable and fibre
router/firewalls.
Do you propose putting the ITR function in the DSL
modem-router-firewall? That is not such a bad idea, since it has
(presumably) a public IP address and so can receive the map reply
message from the globally distant query server (in the case of LISP,
the mapping queries are typically answered by the destination
end-user network's ETR).
Ivip has the option for putting ITR functions in a sending host which
has a public address, or in a device such as a
DSL-modem-router-firewall. It would not be out of the question to
put an ITR function in the sending host behind NAT, but then the
sending host would need to build a persistent tunnel through NAT to
the one or more local query servers - in order to receive mapping
updates from those query servers. That is possible, but not part of
the current plan.
> That's a huge deployment advantage.
I don't see any advantage in terms of deployment, since it involves
changes to more and more equipment, including customer equipment.
Ivip's ITFH (ITR Function in Host) is optional - if it is cheap and
convenient to do this for servers or devices like DSL-routers, then
by all means do so. It only makes sense when the device is
well-connected. It would be a bad idea to put an ITR function in a
host or router at the edge of the network connected by a slow,
expensive or unreliable link such as a wireless link.
> So these CPE devices get packets before they have mappings.
OK - for instance, the ITR function is in a DSL-modem-router-firewall
device.
> 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.
I agree.
> So the cost is *either* first packet loss or sending the packet on the
> ALT using it as a request for a mapping.
These are not the only choices.
Another choice is to using a different architecture with local query
servers - as does APT and Ivip. I think you have approached this
without thinking widely enough about the alternative ways of doing
things which are different from traditional approaches like routers
and DNS.
If you send the packet on the ALT network (for the purposes of
delivering it to the ETR ASAP, as well as to elicit a mapping reply
from that ETR) then you are going to greatly increase the volume of
traffic on the ALT network. Many of these packets will be short -
but what if someone sends a 1500 or 9000 byte packet?
If you don't send the packet via the ALT network, then you either
drop it, or delay it until the mapping arrives. But that could be
longer than 0.5 or 1.0 seconds, considering how many ALT routers the
mapping request packet needs to go through to get to the ETR, how
these ALT routers could be all over the world, and how the ETR could
be on the other side of the world anyway. This is a lot slower than
the current system which usually takes 0.2 seconds or less to
delivers packet anywhere in the world. (The round trip from
Melbourne Australia to Latvia is about 400ms.)
>> 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.
In terms of delaying packets, I agree. Do you agree the long-path
critique is valid?
The long path involves more than delay. It involves traffic flowing
(often) all around the world due to the fact that the highly
aggregated structure of the ALT network will frequently result in
different levels of the ALT hierarchy of routers being distributed
all around the globe, since the physical location of organisations
who are responsible for various parts of the address space does not
correlate very strongly with geography or the topology of the Net.
This is a traffic burden, particularly if you are sending initial
packets on the ALT network for ASAP delivery to the ETR, rather than
just map requests. (However, Ivip involves pumping mapping
information around the globe anyway, and if your ALT network only
handles requests, not traffic packets, the actual volume of traffic
should not be too much of a problem.)
Each operator of each ALT router needs to have a commercial
relationship with those other ALT routers they connect with.
Otherwise, why would they accept the traffic? I haven't seen any
business plan for the commercial relationships which pay for the ALT
routers and their traffic.
Ivip's fast push system involves a charge per update, which will
finance the construction and running costs of most of the fast-push
system, which will be run collectively by the various RUAS (Root
Update Authorisation System) companies, each of which generates the
real-time mapping changes for multiple MABs (Mapped Address Blocks -
BGP-advertised prefixes encompassing thousands, or hundreds of
thousands of micronets).
>> 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 don't recall any prior mention of rapidly reconstructing tunnels to
maintain the ALT topology. I agree with your point 2 that the
tunnels will be reasonably robust due to relying on existing
connectivity which is generally ensured by BGP.
But what happens when two ALT routers loose their connection for a
moment? Do they try to set up one or more tunnels with the same role
in the ALT topology as the one which just died? This is your point
1. It could get messy, but I guess it could be done, by using other
interfaces which, for some reason (I guess) have connectivity while
the interfaces used for the first tunnel don't. But that is the sort
of situation which I think BGP would naturally resolve, generally in
a few seconds or less.
My concern is more about what happens if an ALT router dies. In
your highly aggregated hierarchy, a mid-level ALT router is a single
point of failure for sending mapping requests to all the ETRs in the
branch below this router and from all the ITRs in that branch to ETRs
outside the branch.
When a mid-level router dies, you can't just re-establish tunnels -
it is dead. The routers below need to establish tunnels to another
ALT router which can take the dead one's place.
How is this going to work? Say one lower-level router finds it can't
reach the mid-level router in question, it is going to assume the
mid-level router is dead. So the lower-level router tries to set up
a tunnel to the one or more backups. If it does so, either this
won't work at all, or the next level up will have to adapt to the
original mid-level router having routes for most of its patch of the
ALT address space, but with the backup having the router for the
smaller patch of space handled by the lower-level router which just
made a tunnel to the backup mid-level router.
> I think it's the complete opposite of what you claim. I think BGP will
> be more stable and scalable then the underlying BGP.
I assume you mean that the BGP of the ALT network, operating over
tunnels, will be more stable than the BGP of the Internet. This is
your point 2, and I largely agree. But what if an ALT router dies?
> 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.
I don't understand "diameter" in this context.
> 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.
I am sure you can make the ALT network reasonably robust, at a cost
of complexity and with a loss of the original attractive design goal:
a very high degree of aggregation.
I imagine you can reduce the excessively long paths by collapsing the
network as much as possible to reduce the number of levels a packet
typically has to ascend and descend. This will reduce the
"long-path" problem significantly. But then, each participating
mid-level ALT router (there are fewer of them) covers a larger part
of the address space, and my concerns above become more acute, when
such a router fails or becomes really unreachable.
I imagine you can reduce the geographical scatter component of the
long-path problem by centralizing the ALT routers geographically.
However, that privileges some operators and creates costs and
difficulties for others.
I still think it is fundamentally wrong to have a global query server
network for any system like this, where waiting for mapping replies
involves delaying or dropping traffic packets.
I think a much better solution is to push the mapping to local query
servers in each ISP (APT and Ivip) - and into any larger end-user
networks which want to run their own local query servers (Ivip) so
their ITRs can get marginally faster, more reliable, responses than
by using the query servers of their ISPs.
> 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.
PKI is a great idea, but I think most people believe it is highly
desirable to find solutions which do not require it.
> 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.
Are you discussing just the mapping queries going over the ALT
network? Or are you discussing the use of LISP to enable, for
instance, two IPv6 sites to communicate via the IPv4 Internet, while
one or both sites has no native IPv6 connectivity? A concrete
example would help.
>> 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.
Christian's critique is not that an end-user network which has
(permanently, by some arrangement) a slice of EID space is bound to
its current ISP (the one it uses for connectivity).
The critique is on this potentially erroneous basis: that the
end-user network is bound to maintaining connectivity (via a tunnel)
to the ALT router which handles this part of the EID space. It needs
to do this so mapping queries for its EID space will get to its ETR.
The potentially faulty aspect of this is the assumption that the
end-user network runs its own ETR.
But if its one or more ISPs run the ETR this end-user network uses,
then the end-user network still depends on those ETRs having tunnels
to potentially distant ALT router for its section of the EID space.
I don't know if anyone has considered the scaling problems of a busy
ETR maintaining tunnels to about as many ALT routers as the end-user
networks it handles packets for.
The ALT router for this section of the EID space will, I assume, be
located at some ISP somewhere, or some other commercial organisation
which rents out the EID space to this end-user network.
Maybe that organisation is an RIR. But when this scales to tens or
hundreds of millions of end-user networks (I assume this is a goal of
LISP - it is of Ivip) I doubt if RIRs will want to be dealing with a
hundred million end-user networks directly, either for address
assignment or for tunnels to receive mapping requests to their ETRs
from the ALT network.
For these large scaling arrangements, there will need to be
potentially multiple levels of address splitting. Ivip allows for
this, and for multiple levels of companies providing interfaces to
accept mapping changes from end-user networks (or more likely from
reachability testing companies they hire) and funnelling them to the
limited number of RUAS organisations which run the fast-push mapping
distribution system.
Any way you do this core-edge separation business - LISP, APT, Ivip
or TRRP - if the end-user network gets a patch of stable address
space to call their own, year after year, then that network is going
to depend on some company or other organisation for that space. The
end-user network will need to pay for this, and depend on the
organisation to handle mapping.
In the case of LISP-ALT, the organisation needs to run (or have
someone else run) an ALT router (plus backups) which has a tunnel to
the ETRs in the ISPs which the end-user network is currently using
for access. If that organisation's ALT routers go down, it is not
the fault of the access ISPs - it is up to the end-user network to
ensure it obtains its EID address from an organisation which provides
a reliable ALT router service.
Also - assuming the space is covered by a PTR in order to provide
100% multihomed service for packets sent from hosts in non-upgraded
networks - this organisation has to run PTRs which covers this
end-user's EID space. For this to be scalable (not to bloat the DFZ
routing table excessively, as we go to millions of end-user networks
with EID/micronet space), the PTRs needs to advertise a prefix which
covers the EID space of thousands or hundreds of thousands of
separate end-user networks.
Since the sending hosts (in non-upgraded networks) could be anywhere
in the world and since the ISPs used by all these end-user networks
(covered by the one BGP advertised route) could be anywhere in the
world, in order to ensure reasonably direct path for traffic packets,
there needs to be a largish number of PTRs physically all over the
Net. Then the organisation which runs this PTR system needs to
recover costs from individual end-user networks according to the
traffic the PTRs carry. (This is the Ivip business model for
OITRDs. I am stating this as an imperative for LISP, because I can't
imagine any other business model for PTRs.)
In the case of Ivip, the equivalent organisation needs to do the same
as just stated for OITRDs and provide the real-time mapping
distribution service, with a small charge per update.
Either way, the end-user network has a long-term technical and
commercial dependency on whichever organisation supplies its EID
(LISP) or micronet (Ivip) address space. This is why my message
continued to state that a problem such as this is common to all
core-edge separation schemes:
[Fix? Seems to be a fundamental problem, but every core-edge
separation scheme involves supplying stable EID, micronet etc.
address space to end-user networks, so there must be some
kind of dependence on some organisation - though not
necessarily an ISP.]
{Experiments? There's no need for experiment - problems such
as this can be clearly foreseen.}
So while I could take this off the list of "unresolved" problems for
LISP, since other schemes have comparable problems - I think LISP
could be improved by more clearly stating the types of commercial and
technical relationships each participating end-user network will rely
upon. Also, the physical distance to the ALT router from wherever
the end-user network's ETRs are directly affects the delay
experienced at the start of sessions. I think that is part of
Christian Vogt's concern.
I think I have done a better job of explaining all this with Ivip's
business model for OITRDs:
http://psg.com/lists/rrg/2008/msg01158.html
> 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).
I think a good core-edge separation scheme should make the EID
(micronet) space entirely portable, with little or no compromise in
performance or costs regarding mapping no matter where the end-user
network chooses to connect its EID space (or some part of it) to the Net.
This is easier for Ivip, since the mapping change command only
involves a few dozen bytes and is made quite infrequently.
For LISP-ALT, the mapping connection is an incoming stream of
requests or initial packets which also function as requests. It is
time-sensitive, since only when a response arrives at the ITR can
communications without delay begin. So the physical proximity (delay
and reliability) between the ALT router for this section of the EID
address space and the the ETRs of the ISPs currently used by the
end-user network is really important. I don't mean San Jose to LA
distances - I mean Australia to the USA, Germany to China etc.
These do seem to be a fundamental difference between LISP-ALT and
Ivip. However, both systems will only work well with a widespread
set of PTRs/OITRDs.
>> 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.
OK - I apologise for stating that you thought there was no problem.
I haven't considered MTU problems of sending traffic packets along
the ALT network, in its GRE tunnels (which impose their own
encapsulation overhead) - but I understand the current LISP test
network doesn't send traffic packets over ALT. It is my impression
that your long-term plans are to use the ALT network only for short
map request messages, not go get initial traffic packets to the ETR ASAP.
Version 08 (2008-07-10) introduced a stateless technique and version
11 (2008-12-19) adds a stateful approach, derived from the OpenLISP
project, who regarded the stateless approach as inadequate.
My assessment of both approaches is in a separate message:
LISP PMTU - 2 methods in draft-farinacci-lisp-11
http://www.irtf.org/pipermail/rrg/2009-January/000885.html
I think the stateless section is poorly written and ill-conceived.
The stateless approach for IPv4 DF=1 packets and IPv6 packets (that
is, virtually all traffic) would limit traffic packets to 1464 bytes
(IPv4) or 1444 bytes (IPv6). Only once there was jumboframe links
between every ITR and ETR could L be globally adjusted upwards from
1500 bytes to ~9000 bytes or whatever - but this would not be
possible for a decade or two. Fred Templin expressed the same
concerns in a recent RRG message.
The Stateful approach, which I understand is derived from OpenLISP,
is similar to Ivip's approach:
http://www.firstpr.com.au/ip/ivip/pmtud-frag/
I need to write this up as an I-D, but it is a more detailed spec
than your LISP approach, with mechanisms for occasionally testing for
MTUs longer than the assumed limit and for strictly minimising the
number of traffic packets which are used to probe the PMTU. Every
packet whose length, once encapsulated, is in the "zone of
uncertainty" for this ETR is either delivered or rejected with a PTB.
The former raises the lower limit to the zone and the latter
reduces the upper limit.
>> 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 complete solution to the routing scaling problem involves much more
than a technical design.
All the technical stuff (sometimes split into "architecture" vs.
"engineering") needs to facilitate someone wanting to build and run
each part of it - which generally means they (or someone not too far
removed from them) needs to be able to make money from it.
> 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.
I think my critique is valid - you seem to have no business case for
LISP's Proxy Tunnel Routers.
You are welcome to adopt the Ivip approach for address management and
OITRDs:
http://psg.com/lists/rrg/2008/msg01158.html
This is directly applicable to LISP and PTRs, as long as you have a
concept of a Mapped Address Block, containing many EIDs. For that to
be the case, you need to develop business arrangements concerning who
really "owns" the MAB and how they rent this space out as EID space
for thousands of end-user networks.
>> 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.
The scaling problem of thousands of ITRs continually test
reachability for one ETR (or to every ETR on the LISP mapping list
for a given EID), plus reachability through each ETR to a given
destination network, or of each ITR having to test reachability to
thousands or tens of thousands of ETRs have been obvious from the
start: early 2007.
This is true of LISP, TRRP and to a somewhat lesser extent APT. (I
haven't read RANGER yet.)
Only Ivip avoids these scaling problems by making the end-user
network responsible for their reachability testing and for deciding
which ETR the packets for each micronet should be tunneled to.
> 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.
The alternative has been available to you and anyone else since July
2007: Ivip. A fast-push mapping system to local query servers means
the ITRs don't need to test reachability or make any decisions about
which ETR to use. The mapping has a single ETR address.
What is wrong with this approach?
>>> 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.
OK.
> 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*.
I think this is fine.
However, I think there are sufficient fundamental, well known
problems with LISP-ALT that if this was my proposal, I would fix them
before asking people in general to join an IETF WG and help me with
it - or drop the proposal.
>> 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.
I am all for detailed engineering, running tests etc. However, the
worst problems I perceive with LISP-ALT will not be illuminated by
any amount of testing, as I explained in the message you are
responding to.
Do you think Ivip is so overblown and over-complex that it warrant's
no serious consideration?
Just because I write stuff in detail doesn't mean the system itself
is over-complex. Ivip ITRs and ETRs are much simpler than LISP ITRs
and ETRs.
I have been giving your work the honour of detailed critiques for 18
months. I would appreciate you and your colleagues returning the
favour by reading:
http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf
http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00
Ivip business models: fast push & OITRDs
http://psg.com/lists/rrg/2008/msg01158.html
and telling me - and the RRG - what you think.
Also, I am keen to know from you, your Cisco colleagues and from the
folks at Juniper how practical it would be to create firmware
upgrades for all the DFZ routers in use ca. 2014 or whatever -
whenever the routing scaling solution is to be implemented.
I think it is practical and highly desirable to encode the ETR
address in the IPv4 header (actually 30 bits, which is fine) or a 20
bit prefix label in the IPv6 header. Then, in the longer term, we
don't need encapsulation, its complexity, its overhead and its damn
PMTUD problems.
As far as I know, both these proposals could be implemented as
firmware upgrades, or built-in optional features, in the DFZ routers
which are likely to be in use in 5 years time, but only you guys can
say this is so or not:
ETR Address Forwarding (EAF) - for IPv4
http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01
Prefix Label Forwarding (PLF) - for IPv6
http://www.firstpr.com.au/ip/ivip/ivip6/
Maybe we can do that in time for the introduction of the routing
scaling solution - and thereby completely avoid encapsulation and its
PMTUD complexities.
On mobility - what is your objection to this arrangement? ETR-like
Translating Tunnel Routers with two-way encrypted tunnels to mobile
nodes. Mapping only changes to a new TTR when one is really needed 0
which is typically only when the MN moves 1000km or more. So mapping
changes are not at all frequent and in particular are not needed
every time the MN gets a new CoA:
http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf
If I was proposing to the IETF that a WG be formed for my project, I
would first want to establish for myself - and for IETF people in
general - that my project was either the best in its class, or one of
the very few with the most promise.
I don't see how you can do that when you fail to read - or at least
fail to discuss in public - alternative schemes to LISP.
Ivip and APT are broadly comparable to LISP - they are all core-edge
elimination schemes for both IPv4 and IPv6. They are both well
enough documented to be suitable for serious critiques from anyone
who believes LISP's approach is superior.
Just because you have more people - with more experience and
resources - working on LISP and have running code, doesn't mean your
LISP-ALT design is better than APT or Ivip.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
