Short version: If Noel's statements:
http://www.ietf.org/mail-archive/web/ietf/current/msg70356.html
reflect the position of most LISP protocol developers
and if I have understood him correctly then we are all
agreed that the LISP protocol in its current form does
not introduce new namespaces and so is not a Loc-ID
Separation protocol.
I understand that Noel's regards the current form of
the LISP protocol is just a first stage - implicitly
one which is not expected to provide an acceptable
solution for the scalable routing problem: multihoming
and mobility for millions and billions of end-user
networks and devices without increasing the burden on
the BGP DFZ routing system or introducing other scaling
difficulties, unfair cost burdens etc.
I understand that he intends the second, long-term,
stage for the LISP protocol project to introduce a true
Loc-ID Separation system, with a new namespace for
Identifiers. This would require major changes to all
host stacks and application programs, just like GSE,
HIP or ILNP.
Maybe this has been explained in public elsewhere - if
so, I missed it.
If this is the real plan behind the LISP protocol, then
instead of arguing that it needs a new name, I would
argue that "Locator - Identifier Separation Protocol"
needs to be prominent in its name, but with suitable
qualification that this is a long-term goal, not a
part of the current protocol.
Hi Noel,
Thanks for your reply:
The LISP protocol does not introduce a new namespace for
Identifiers (for hosts, interfaces or whatever).
The long-term concept is that it needs to be a phased introduction:
initially, IPvN addresses are used on both sides of the mapping in order to
minimize the amount of new stuff that has to be written/deployed before we
can start to make use of the system.
Once the mapping system, edge boxes, etc are widely deployed, then we can
move on to doing things like adding support for new namespace(s), but it will
(for the forseeable future) be on the locator side, not the identifier side,
for the simple reason that to deploy a new identifier namespace,
ubiquitously, means changing all the hosts, and that's just too hard. When a
new locator namespace is added, however, the hosts can remain blissfully
unaware of that.
Indeed - the LISP protocol does not introduce a new namespace for
Identifiers. Nor, currently, is there any new namespace for Locators -
since both roles are played by global unicast IP addresses.
I agree that you could add new namespaces for Locators - such as for
getting packets to ETRs by some other means the TCP/IP - without hosts
needing to be changed.
I agree with you that in order to introduce a new namespace for
Identifiers, you would need to change the hosts - the stacks and the
applications.
If you look at the details of the mapping system, it carefully has hooks in it
for support of new namespaces, and in fact that have been (over the years) a
number of different suggestions for new locator namespaces (e.g. for use with
MPLS fabrics). Those are all still very much just suggestions, but if LISP
catches on I have no doubt that some will almost certainly happen.
Rome wasn't built in a day...
OK - I understand that you agree with me that the LISP protocol, in its
current form (as per the current drafts and soon-to-be RFCs), does not
introduce a new namespace and therefore is not a Loc-ID Separation protocol.
I don't assume you speak for other LISP protocol developers and I am
keen to know their views. However, your work has been a central
inspiration to the LISP protocol developers, so I would not be surprised
if some, many or all of the others agreed with what I understand is your
position.
I know from a personal communication nearly two years ago that at least
one other key LISP protocol person shares your intention that the
current LISP protocol arrangement is just a stepping stone to a real
Locator-Identifier Separation protocol. Until now I thought his views
were at odds with the LISP protocol project.
Now I think the real long-term intentions of the LISP protocol project
have been either actively hidden, or at least inadequately articulated,
with the result that many people didn't understand the true nature of
the project. (Or did everyone else understand this long-term stuff and
for some reason I missed it?)
Perhaps this long-term view of changing everything to a real Loc-ID
Separation system is behind the otherwise cryptic footnote:
LISP -- We've Got Bigger Fish To Fry...
at http://lisp.cisco.com and some other pages there.
Underlying all this is a profound dislike of today's Locator-Identifier
Overloaded IP addresses. This is a sentiment shared by quite a lot of
people for decades.
When I thought about the LISP protocol in June 2007 and came up with
what I now called DITRs (Default ITRs in the DFZ) to solve the problem
of packets sent from networks without ITRs, I assumed that LISP was
intended to be the actual solution to scalable routing problems. I also
thought of TTR Mobility on that day and wrote about it to the RAM list:
http://www.ietf.org/mail-archive/web/ram/current/msg01518.html
The same thing as DITRs appeared in the LISP protocol as PITRs (Proxy
ITRs) in December that year.
Since July that year I have been developing Ivip, which shares many
fundamental principles with the LISP protocol, and suggesting
improvements to the LISP protocol based on my work.
All along I assumed that the LISP team was dedicated to a scalable
routing solution which supported the current IP address arrangements -
and therefore would not require any stack or application changes.
Once I thought in detail about Loc-ID Separation and came to learn more
about GSE, HIP and ILNP, I realised that I had been mistaken about
thinking that the LISP protocol and Ivip (which I derived from the LISP
protocol, including with some misunderstandings which turned out to be
useful) were Loc-ID Separation protocols.
Then, I thought that it was simply a mistake that you and the other LISP
protocol developers thought your protocol was Loc-ID Separation in the
first place, and for some reason continued to think this.
I assumed then that your aims with the LISP protocol were the same as
mine with Ivip. If the consensus view of other LISP developers accords
with my understanding of what you just wrote, then I have been
completely mistaken.
I completely reject the long-held belief of many IETF people that the
Internet would be better with Loc-ID Separation. I agree that it would
be architecturally more pure - but I regard the current Locator and
Identifier overloading arrangements as A Very Good Thing:
"Overloading" of Loc & ID functions is good for hosts and should be
maintained 2010-06-22
http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html
I suggest this whole Loc-ID Separation yearning be tagged "Be careful
what you wish for" and put on prominent display for the edification of
future generations.
This is especially so in a world where most hosts are battery operated
devices hanging off potentially slow, expensive, high-latency,
high-packet-loss 3G etc. wireless links.
Ran Atkinson and his supporters with ILNP were at least up-front about
their intentions - they wanted to change everything to be, in their
view, "architecturally correct", "elegant", "pure" or whatever. There's
no chance they will ever achieve this, because the current Internet
protocols are just fine - and since Loc-ID Separation only provides
significant benefits once it is adopted by everyone (meaning all stacks
and all applications have to be seriously rewritten). This will never
happen.
Likewise, even if the current version of the LISP protocol was
successful and widely adopted, there would be insurmountable barriers to
introducing true Loc-ID Separation - all applications would need to be
rewritten, not only to handle the new Loc-ID things but also to work
with conventional hosts, with and without Loc-ID capable applications at
the other end. Even a few seconds consideration of the coding and
debugging difficulties would have application programmers screaming with
horror.
After reading your message, I now suspect that the LISP protocol as it
is defined today is like a Trojan Horse, supporting the current Loc-ID
Overloaded IP address arrangements out of necessity (for widespread
adoption), rather than out of a belief that it the best way to run the
Net. Now I see the real long-term goal has always been changing
everything just as much as ILNP would.
So by all means keep using a name like "LISP" - now the Good Ship LISP's
true colors are flying on the mast. Still, I think it would be best to
rename the project to avoid overloading the term for the programming
language with a second and unrelated meaning. Perhaps:
LISPEV Locator-Identifier Separation Protocol EVentually
LTLISP Long-Term Locator-Identifier Separation Protocol
LISPBS Locator-Identifier Protocol By Stages/Stealth
To ensure Truth in Advertising, I suggest the LISP protocol team
corrects statements such as these:
http://lisp.cisco.com/lisp_over.html
LISP creates two namespaces and uses two IP addresses:
Endpoint Identifiers (EIDs), which are assigned to end-hosts,
and Routing Locators (RLOCs), which are assigned to devices
(primarily routers) that make up the global routing system.
By splitting the device identity, its Endpoint Identifier (EID),
and the device location, its Routing Locator (RLOC), into two
different namespaces, improvements in scalability of the
routing system can be achieved through greater aggregation of
RLOCs.
The use of the term "namespace" here is erroneous. "Subset" would be
better - though "namespace" sounds more impressive to those who don't
understand.
As I think you agree, the EID subset of global unicast addresses does
not involve a new namespace - EID and non-EID global unicast IP
addresses are both interpreted according to the single global unicast
address space which is applicable (the IPv4 one or the IPv6 one).
Likewise, I think you would agree that introducing cellphones and their
nation-wide network of exchanges and base-stations to the phone system
didn't involve the creation of a new namespace. An increasing subset of
the phone numbers in the North American 10 digit system are for
cellphones, and the exchanges route the call establishment messages for
these calls in different ways than they do for non-mobile services - but
there is no new namespace. The numbers used for cellphone and
non-cellphone services are all 10 digit numbers which are interpreted
according to the one namespace.
Also regarding Truth in Advertising, I don't recall anything in the LISP
protocol drafts which refers to the currently proposed protocols being a
first stage in preparation for something completely different. I just
scanned draft-ietf-lisp-15 and saw no such thing.
Assuming your statements represent the true nature of the LISP protocol
project, then of the scalable routing protocols which are still under
development, only two remain which are intended to to retain the current
Loc-ID Overloaded arrangements: Ivip and Fred Templin's IRON. As far
as I know, the now defunct APT project (Dan Jen and Michael Meisel) had
the same intention - it was not a Trojan.
- Robin http://www.firstpr.com.au/ip/ivip/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf