Short version: LISP-ALT seems liked a rushed development
which won't be widely enough adopted even if
there are RFCs and interoperable
implementations by 2012.
The work which preceded the various I-Ds.
Dino, in response to my concern that the LISP-ALT development is
too rushed, you wrote:
> How about the world is going too slow?
In the 2.3 years since RAWS in Amsterdam the DFZ routing table
has grown from about 200k to about 275k. There may be a slight
glitch downwards due to the economic crisis in recent months:
http://bgp.potaroo.net/bgprpts/bgp-active.png
That is a growth rate of about 15% PA.
We have growing problems with:
1 - This growth rate increasing the cost of of routers
in the DFZ, which is a burden on all ISPs and therefore
all Internet users.
2 - Excessive constraints in PI space which is an attempt to
reduce the above growth rate.
3 - With the increasing number of end-user networks which want
multihoming, inbound traffic engineering and portability
either not being able to get any of these, or having to
pay much more for it (and cause burdens on the DFZ) than
would be the case with a good scalable routing solution.
Whenever IPv6 is widely adopted, the same things will happen
there too.
However, I don't think these problems are so urgent that we
should rush into re-engineering the Net with a poorer solution
than if we spent a few more years working on it. We will be
stuck with the solution for decades.
I imagine you could create LISP-ALT RFCs by the end of 2010 and
have interoperable implementations in software and in some
hardware routers by the end of 2011.
But I can't see how you are going to get the widespread adoption
of LISP-ALT EID space by most end-user networks (which want
multihoming, TE and portability), from the smallest (SOHO etc.)
to the largest (corporations, universities and government
departments) in 2012 or at any other time.
By then you will probably have figured out business arrangements
for EID allocation and for running PTRs. I imagine it would be
be similar to parts of:
http://psg.com/lists/rrg/2008/msg01158.html
You will probably have also solved the PMTUD problem with a
judicious use of the OpenLISP stateful approach, requiring all
DFZ routers to return 16 bytes or more past the IP header in
their PTB messages, minimising the number of packets the ITR
stores the nonce for and allowing for occasional checking for
growth or reduction in the path MTU to each ETR. I think the
result would resemble:
http://www.firstpr.com.au/ip/ivip/pmtud-frag/
LISP-ALT would still have the initial packet delay problem, the
long-path problem and the difficulties in building a big ALT
network which has redundancy and meshiness - or whatever is
required for robustness.
None of these problems would present serious practical
difficulties in the test network or in the first months or year
or two of deployment - because there would be small number of
ALT routers.
However, anyone concerned about the long-term future would be
well aware of these problems. I don't think you can solve these
problems in any elegant, efficient manner - because they are
fundamental problems with the LISP-ALT architecture.
ALT is certainly more elegant than CONS, with its new network
elements of CARs and CDRs which needed to be created from scratch.
AFAIK, an ALT router can be created by correctly configuring
various functional elements which are already present in a good,
flexible, hardware-based or software-only router.
The ITR and ETR functions need new code.
By 2011, I figure you would also have figured out standardised
approaches by which an ISP could manage its ETRs to securely
make tunnels to the upstream ALT routers it needs to get map
request messages.
You would also need a secure and reasonably automated method by
which end-user networks could identify themselves to ISP ETRs
for the purposes of telling the ETR their EID, so the ETR would
be prepared to convey mapping for that EID to the ALT routers.
Maybe you will make the ALT network handle the initial packets
(which also function as map requests) - but then the ALT network
needs much greater capacity, for a small reduction in the delay
of initial packets.
That would worsen the traffic burden on ALT routers and require
more care about the commercial relationships between all the
organisations who run these ALT routers. No-one is going to
carry packets with a bunch of mapping requests, and especially
the greater volume of initial traffic packets, unless they get
paid by whoever sends them and/or whoever accepts them.
Circa 2012, I think it would be unlikely that any large end-user
network which already has PI space would want to convert it to
LISP EID space. They would need to run PTRs for that space.
That is not so hard if all the EIDs are still in the one
geographic area. However, if they wanted to use their EIDs
anywhere on the Net, they would need PTRs in or near such
locations. They would gain the ability to split their address
space for physically separate (in terms of BGP border router)
sites into smaller pieces than the current BGP /24 limitation
allows. This will become more important as IPv4 space becomes
more and more valuable - but only for networks which have many
sites they want to connect via multiple, physically separate, ISPs.
However, all their network would now suffer from the initial
packet delay problem. Initially, that might be tolerable for a
university. But any corporation which is vying for customers
and wants its web-sites to be responsive would look into the
future and see that LISP-ALT's long-path problem is going to get
worse if and when it becomes very widely adopted.
You may well be able to get some adoption of LISP EID space by
smaller networks which can't get PI space today.
ISPs would presumably be able to run ITRs and ETRs without major
expense - either with firmware updates for their existing
routers of via inexpensive or open-source software to run on
COTS servers, at least initially.
By then - 2013 or beyond - other scalable routing solutions will
be better developed and probably have their own WGs, test
networks etc. I think the scalable routing problem would be
more widely known within and beyond the IETF - especially as
IPv4 space becomes more scarce and valuable.
I can't imagine that LISP-ALT could scale well to your stated
goal of 10^10 EIDs. As I wrote previously, the ALT network
would have to be so vast that the initial packet delay problem
would be serious, - especially with meshiness or whatever for it
to be robust. This will affect some DNS requests and replies
too, not just TCP SYN and ACK packets.
The smaller and more numerous the ITRs (to spread the load of
traffic) the more problems there will be with initial packet
delay due to the ITRs not having the mapping already cached.
More numerous ITRs will also drive up the query traffic on the
ALT network.
The local query server schemes (APT and Ivip) have no initial
packet delay problems. They need to distribute and store
mapping data all over the Net, slowly or in real-time. Today's
COTS (Commercial Off The Shelf) servers can store and transfer
the data just fine for 10^8 to 10^9 EIDs/micronets. If and when
we get to 10^10 EIDs/micronets (the vast majority of which must
be for personal mobile devices), a COTS server will probably
have 10^1 or 10^2 times more RAM, CPU power etc.
The mapping distribution for APT and Ivip can be done with
purpose-built, streamlined, mechanisms which are not as fussy as
a LISP-ALT-style global query server network where the whole
thing depends on a lonely query packet traversing a global-scale
network, and its equally lonesome response packet making its way
back via the Internet.
I doubt that anything other people write will convince you not
to push/rush ahead with LISP-ALT. If you can't imagine a better
architecture, then I think you should develop it ASAP - in a WG.
My point in writing is to remind onlookers that there are other
people in this field who think ALT has too many fundamental
problems to be the optimal long-term scalable routing
architectural enhancement for the Internet - and that there are
other approaches, which are being developing more slowly, which
show much greater promise.
Vince, thanks for filling in the background on the Internet
Draft dates I listed. You wrote:
>> LISP-ALT is the most frequently discussed solution to the routing
>> scaling problem. Yet it is a more recent development than APT or
>> Ivip - and I think it is the most problematic of the three.
>
> As I have explained more than once already, your timeline is simply wrong.
My timeline was stated to be in terms of I-D publication dates,
which are correct.
> The base LISP spec, draft-farinacci-lisp-11.txt in its current incarnation,
> was a direct result of design discussions that occurred in October, 2006,
> at the IAB-sponsored Routing and Addressing Workshop in Amsterdam. The first
> version of draft-farinacci-lisp appeared for select reviewers on December 1st,
> 2006 and was published on January 22nd, 2007.
I recall someone writing that APT development was taking place
in late 2006 too.
> The LISP+ALT spec, draft-fuller-lisp-alt-03.txt in its current incarnation
> (and originally termed "LISP 1.5"), was a direct result of discussions at a
> lunch meeting during the November, 2006 IETF plenary in San Diego. Small
> group discussions occurred for several months prior to taking it to the RAM
> list in June, 2007 though the first version of the draft was not published
> until November, 11th, 2007.
The only June 2007 message I can find which relates to ALT is
your "Preliminary thoughts on LISP 1.5" (2007-07-21), which is
largely a private message from 2007-04-04:
http://www.ietf.org/mail-archive/web/ram/current/msg01562.html
This includes "we're looking for alternative methods that don't
introduce enormous amounts of complexity". Looking back, this
is clearly an early description of LISP-ALT. Maybe it is also
an early description of CONS, which appeared in an I-D on
2007-07-30.
If you developed ALT so early, then I don't understand why you
published and promote CONS in July 2007 CONS is harder to
understand, design and implement than ALT, and is still a global
query server system.
I was the only person to write a substantial response to the
above mentioned message, noting that I couldn't clearly
understand it - and that point 6 appeared to describe the same
thing as my Ivip "Anycast ITRs in the core", now known as Open
ITRs in the DFZ (OITRDs).
Despite Dino and I think others either criticised or ignored my
"Anycast ITR in the Core" idea from 2007-06-15 onwards. The the
same idea materialised as LISP Proxy Tunnel Routers on
2007-12-05 in draft-lewis-lisp-interworking-00.
My timeline concerned I-D dates. Since you mention the work
which preceded this, here are the Ivip dates:
I thought of (what were later known as) OITRDs and the overall
TTR mobility scheme on 2007-06-14 and posted it to the RAM list
the next day. All other Ivip things were developed after that.
Urged on by Dino and others, I wrote up an I-D ASAP. This, in
2007-07-15, also included the fast push mapping distribution
system and local query servers - both full-database and caching,
with the ITR being notified if the mapping changed for any
micronet it recently requested mapping for. This I-D also
included ITR functions in sending hosts.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
