Subject: Re: [RAM] Incremental Deployment of LISP

From: [email-masked] (Noel Chiappa)
Date: Thu, 29 Mar 2007 15:54:25 -0400 (EDT)

> From: Roland Dobbins <[email-masked]>

    > The DNS won't work, and deploying some other infrastructure .. to
    > handle lookups is a nonstarter, IMHO.

OK, so what will work? :-) More of what we've already got, because anything
else is too painful to deploy?

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 29 Mar 2007 13:08:09 -0700

On Mar 29, 2007, at 12:54 PM, Noel Chiappa wrote:

> More of what we've already got, because anything

Essentially, yes - updated routing protocols, some new lookup service  
deployed -on the network infrastructure devices themselves and  
operated by the network infrastructure operators themselves-, etc.

But the entire workable solution has to be within the realm of the  
network infrastructure, there can't be any dependencies upon sysadmin  
groups, etc., because of the silos (both natural and unnatural) in  
which the relevant skillsets and responsibilities and interests of  
these groups seem to pretty much universally reside.

In other works, router jockeys are generally just router jockeys, and  
not sysadmins, too; box jockeys are generally just box jockeys, and  
not router-monkeys, too.  And never the twain shall meet for  
architectural purposes, rarely enough even for  operational purposes,  
unfortunately.  So, the lookup function must be self-contained/- 
maintained, IMHO.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

         Words that come from a machine have no soul.

                       -- Duong Van Ngo

---

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 29 Mar 2007 14:19:49 -0700

>Essentially, yes - updated routing protocols, some new lookup service
deployed 
>-on the network infrastructure devices themselves and operated by the
network 
>infrastructure operators themselves-, etc.

An operative design consideration is how stable the interfaces are
between the transit domain (e.g., the ISP-supported Internet) and the
supported enclave (e.g., a corporation's AS). Many relationships will be
very stable such that the interface pairings are essentially constant
due to the (often substantial) inertia of established business
relationships between a corporation and its ISP(s). In such common
situations, I would imagine that such pairings, which constitute the DNS
entries, can last for years or even decades such that even very old DNS
entries will be adequate.

Conceivably, other relationships may be briefer in duration, requiring
DNS updates to occur at a higher rate. But what is the worst case (i.e.,
most brief) address pairings that are currently anticipated and what are
the environmental factors that determine that rate (e.g., what
environments are we actually worrying about in this discussion)? 

Put another way, I don't understand why this proposed use of DNS would
be any worse (i.e., more challenged) than current uses of DNS for
identifying mail servers or other traditionally supported services.

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 29 Mar 2007 14:25:27 -0700

> identifying mail servers or other traditionally supported services.

Because there will be a -lot- more lookups, critical to -all-  
communications relationships, everywhere.  DNS flakiness certainly  
can result in service/communications unavailability, but it isn't a  
guarantee.

And the DNS contains a mess of unpatched, insecure hosts which nobody  
maintains - this is true of routers and other network infrastructure  
too, to some extent, but less than the DNS, IMHO, and, unlike DNS  
servers, these devices will -have- to be upgraded to work with the  
new system.

                       -- Duong Van Ngo

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Mar 2007 14:41:24 -0700

> can result in service/communications unavailability, but it isn't a  

I don't see that at all; you use the DNS to find out where
the service lives, and then you go knock on the door to see
if there is anyone home. It would be no different than the
way the DNS works today.  

Fred
[email-masked]

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 29 Mar 2007 14:48:52 -0700

On Mar 29, 2007, at 2:41 PM, Templin, Fred L wrote:

> It would be no different than the
> way the DNS works today.

It would be in the sense that -routing of packets- would break  
without it, and a critical dependency for routing packets would for  
the first time in the history of the Internet be outside the control  
of network operators, thrust upon people who don't understand and  
don't want the responsibility in the first place.

Also, there's a whole lot of TCP/IP communications which take place  
which require no DNS lookups at all; for the communications which  
take place which require DNS, the ratio of packets to DNS lookups is  
very high, and the amount of dynamism-induced periodic/ongoing DNS  
lookups is very low.  With LISP or a similar proposal, this would  
change.

                       -- Duong Van Ngo

---

From: David Meyer <[email-masked]>
Date: Thu, 29 Mar 2007 13:52:20 -0800

> lookups is very low.  With LISP or a similar proposal, this would  

	FWIW, LISP 2 (the DNS variant) is most likely an
	non-starter (as Dino mentioned) for all of the reasons
	we've been discussing here. As I understandn it, LISP 2
	was included for completeness.

	--dmm

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Mar 2007 15:04:48 -0700

> -----Original Message-----
> From: Roland Dobbins [mailto:[email-masked]] 
> Sent: Thursday, March 29, 2007 2:49 PM
> To: [email-masked]
> Subject: Re: [RAM] Incremental Deployment of LISP
> 
> 

When the DNS is up, the situation would be *way better* than
for today since countless IPv6 services would be available.
When the DNS is down, the situation would be no worse than
for today since IPv4 services would still be reachable. But,
when is the DNS ever down?

Fred

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 29 Mar 2007 15:11:52 -0700

On Mar 29, 2007, at 3:04 PM, Templin, Fred L wrote:

>  But,

All the time, in different localities (for widely varying values of  
'locality').

Anyways, this issue has been beaten to death, as dmm indicated.  In  
terms of LISP, it only applies to LISP v2, which was included mainly  
for the sake of completeness.

                       -- Duong Van Ngo

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Mar 2007 15:16:30 -0700

> All the time, in different localities (for widely varying values of  

I think the way you define "locality" is the crux of the
matter; if you mean within an enterprise/site, then you
can just use IPv6 routing no problem.

Fred

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 29 Mar 2007 15:21:32 -0700

> can just use IPv6 routing no problem.

That's situationally-specific, too.  But this problem aside, the  
siloing/externality issue is a showstopper, even if the other issues  
weren't of consequence.

I'm not going to comment on this issue further, as I don't want to  
keep spamming the list.

                       -- Duong Van Ngo

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Mar 2007 15:26:35 -0700

> I'm not going to comment on this issue further, as I don't want to  

That's fine with me, but I still don't see any problem.

Fred

---

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 29 Mar 2007 17:11:31 -0700

>It would be in the sense that -routing of packets- would break without
it, 
>and a critical dependency for routing packets would for the first time
in 
>the history of the Internet be outside the control of network
operators, 
>thrust upon people who don't understand and don't want the
responsibility 
>in the first place.

Speaking as a (very) large end user representing what I (perhaps
incorrectly) expect the ISPs supporting us to do, I believe that this is
not a problem for the following reason:

We negotiate our Internet service with our ISPs. This is an involved
process that is not done overnight, to say the least. Each ISP provides
ingress and egress paths to the Internet for us. The disproportionate
percentage of our traffic goes to a finite number (let's say a few
hundred -- but this number is not relevant) of remote ASes via a small
set of ISP-provided routers that are connected to a small-set of POP
routers that we provide. These ISP-provided routers will not be looking
up DNS entries at any point because the latency involved with DNS
lookups could not support the very high data rates that they have
committed to support in their business agreements with us. For this
reason, I expect that the ISPs will periodically map the Remote AS-to
Remote-Internet-tunnel-endpoint relationships contained in the then
current DNS tables (from the perspective of their position within the
Internet (e.g., in regards to load-balancing and multi-homing and
traffic engineering connections in accordance with our agreements
together)) via a mechanism of their choice. This calculation will create
a database that they will then load into an appropriate cache within
their POP routers. This cache will contain the calculations for
***entire Internet DNS table*** because they must not presume that all
of our traffic will always remain limited to the few hundred remote ASes
that we primarily deal with. I further presume that only deltas
(changes) will need to be loaded and that the cache updates will not
require the routers to go off-line at any point.

---

From: David Conrad <[email-masked]>
Date: Fri, 30 Mar 2007 11:22:27 +0100

> else is too painful to deploy?

At one extreme, there is the pull model.  The DNS is an example.

The other extreme is a push model, where the mapping is flooded to  
the entities that are doing the mapping.  There are a number of  
protocols that do this, that I'm sure you're aware of.

Both extremes have advantages and disadvantages.  Assertions that a  
push model like the DNS won't work because of the way the DNS has  
historically been implemented are, of course, specious.  The DNS  
protocol is a relatively lightweight protocol that we understand  
fairly well (warts and all).  I'm sure someone can come up with  
another protocol that implements a identifier to locator mapping by  
fetching the data on demand, but I suspect the result will look a lot  
like the DNS (hopefully without the warts).

The assertions that something like the DNS won't work because of  
circular dependencies are also wrong, since routing could depend on a  
subset of directory and the directory would depend on a different  
subset of routing.  For example, in a simple model where you have 2  
different non-intersecting addressing universes (call them  
"identifiers" and "locators" just for fun), the mapping service  
devices would be exclusively numbered in the locator space.

My suspicion is that a pull model is the most likely to provide the  
amount of information hiding (of a sort) necessary for us to get to  
the level of scalability we're looking for, and we'll just have to  
eat the initial RTT latency hit.  It is probably worth remembering  
that the edge is already used to a similar latency hit, after all,  
very few people put IP addresses as the URL in their browsers...

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Fri, 30 Mar 2007 11:26:56 +0100

On Mar 29, 2007, at 10:25 PM, Roland Dobbins wrote:
> And the DNS contains a mess of unpatched, insecure hosts which  
> nobody maintains - this is true of routers and other network  
> infrastructure too, to some extent, but less than the DNS, IMHO,  
> and, unlike DNS servers, these devices will -have- to be upgraded  
> to work with the new system.

Please make a distinction between the DNS as a protocol and the DNS  
as it has been implemented.

The DNS protocol is a relatively lightweight primarily UDP-based  
protocol that can fall back to TCP in certain circumstances.  Blaming  
that protocol for the sins of poor implementations seems a bit silly.

Thanks,
-drc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 30 Mar 2007 13:32:51 +0200

> when is the DNS ever down?

I don't think an IPv6-only solution is an attractive option...

But let me answer your question with a question: why don't firewalls  
put DNS names rather than IP addresses and ranges in their  
configurations?

And arguably, a "jack up" encapsulation box would be more critical  
than a firewall. With a firewall, you may be able to filter on other  
stuff if a DNS lookup fails, which isn't much of an option after a  
failed locator lookup.

Iljitsch

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 30 Mar 2007 15:22:29 +0200

On Fri, Mar 30, 2007 at 01:32:51PM +0200,
 Iljitsch van Beijnum <[email-masked]> wrote 

> put DNS names rather than IP addresses and ranges in their

Some do (IOS, Linux' netfilter, BSD's pf). It is typically regarded as
a bad idea for security (at least until DNSSEC comes) but it works.

We just miss a way to honor the DNS TTL in these configurations.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 30 Mar 2007 15:20:29 +0200

On Fri, Mar 30, 2007 at 11:26:56AM +0100,
 David Conrad <[email-masked]> wrote 

> as it has been implemented.

And also please make a distinction between the protocol, the
implementation, and the social infrastructure which, today, operates
it.

Roland Dobbins said:

> network infrastructure, there can't be any dependencies upon
> sysadmin groups, etc., because of the silos (both natural and
> unnatural) in which the relevant skillsets and responsibilities and
> interests of these groups seem to pretty much universally reside.

You can still use the DNS, the protocol and may be even the DNS, the
software, without relying on the social infrastructure (ICANN, the
registries, the name server operators). 

For instance, we could ask the IANA for a new DNS class (currently, IN
is the only one in wide use, CH being the closest second), set up a
new root which will depend only on the operator community (may be
through the RIRs) and then happily use the DNS protocol and the DNS
implementations, in a "restricted" environment (much more controlled
than the DNS as it is today).

This would avoid reinventing a mapping protocol which, as David Conrad
said, would probably be very close from the DNS.

---

From: Peter Sherbin <[email-masked]>
Date: Fri, 30 Mar 2007 06:32:14 -0700 (PDT)

Speaking as a (large) ISP I hear a client wanting a sort of a private network with a
kind of a class of service at price of a shared best effort bandwidth. TANSTAFL :)

Thanks,

Peter

> require the routers to go off-line at any point.

____________________________________________________________________________________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

---

From: Russ White <[email-masked]>
Date: Fri, 30 Mar 2007 10:05:53 -0400

> not a problem for the following reason:

It might not be a problem for a very large enterprise along the edge. But:

1. What about MANET?

2. What about wireless laptops roaming around, even in venues like the IETF?

3. What about experimental concept testing?

4. What about little users, like SOHO and individual users in their homes?

I suppose you could say: "Well, there will always be a service provider,
so this isn't a problem." While the service providers on list would love
to hear that (it's akin to the little bells on the cash register
ringing), I don't think it's the best thing for the Internet or IP
networks in general.

:-)

Russ

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Mar 2007 08:36:21 -0700

I think the subject of this message hits the mark, and
maybe there is some confusion about what needs to go
in the global DNS. Only FQDNs with locators for egress
tunnel routers need to go in the global DNS, and that
is not a lot more than what we are asking the global
DNS to carry today.

FQDNs for the services themselves are not resolved in
the global DNS; they are resolved in site-specific name
services instead.

Fred

> From: Stephane Bortzmeyer [mailto:[email-masked]] 
> Sent: Friday, March 30, 2007 6:20 AM
> To: [email-masked]
> Subject: [RAM] The DNS? Which DNS? (Was: Incremental 
> Deployment of LISP
>

---

From: David Meyer <[email-masked]>
Date: Fri, 30 Mar 2007 08:12:02 -0800

> the global DNS; they are resolved in site-specific name

	I've said this once already, however, it might be
	instructive to look at the other existing instance where
	this has been tried, i.e., carrier/infrastructure
	ENUM. There are some lessons, both technical and
	non-technical to be learned there. See e.g.
	http://voipandenum.blogspot.com/2006/03/dallas-treaty-on-infrastructure-enum.html

	--dmm

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 30 Mar 2007 09:49:57 -0700

> registries, the name server operators).

When I say 'the DNS', I mean the system, not the protocol, as well as  
the social infrastructure.  The protocol isn't at issue, agree  
completely.

That's been the convention for many years, by the bye - 'DNS' =  
protocol, 'the DNS' = system.

;>

                       -- Duong Van Ngo

---

From: "Fleischman, Eric" <[email-masked]>
Date: Fri, 30 Mar 2007 10:49:58 -0700

No, I'm not talking about a private network, I am rather attempting to
talk about the algorithmic change that is embedded within LISP.

Last night it occurred to me that this particular posting of mine
presumed too many concepts and that I owe a more complete explanation to
this list. Before doing so, I'd like to state that I am excited about
the LISP concept itself, but not "sold" on any specific LISP
alternative. The reason I am defending the DNS alternative is because I
believe that the analysis that have been posted to this list concerning
the DNS alternative have not considered the implications of the powerful
algorithmic change latent within the LISP concept itself.

I believe that LISP offers the Internet a very valuable abstraction that
occurs at the ISP itself, which simultaneously offers both the ISP and
its customers considerable business advantages over the current system
while also addressing the Internet scaling problem, particularly the BGP
scaling issues.

For example, perhaps many equate the tunnel endpoints to the PE-CE
boundaries defined by L3VPN. This may indeed be the case, but I believe
that it is a local ISP engineering decision concerning where those
tunnel end points actually occur. The tunnels can be highly aggregated.
Alternatively, they can be highly customer specific.

Some may equate the size of the DNS table with the current Internet BGP
table. This may or may not be the case depending on how aggegatable the
LISP implementation turns out to be (e.g., tunnel end point placement
within the ISPs). Regardless, I believe that a local summary of that DNS
table from the point-of-view of each specific ISP router servicing a
tunnel endpoint will be simpler than the DNS tables themselves and will
be smaller than today's Internet BGP tables. (It is that local route
summary that I was describing in my previous posting below.)

There are two reasons for this:
1) Larger ISPs will probably have economic incentives to locally route
as many packets as possible within their own infrastructures.
Specifically, they will probably retain their L3VPN and L2VPN product
offerings. For example, the ISPs with whom we have negotiated MPLS
service connectivity are likely to continue to offer us this service.
More generally, in LISP the connections of any service that is localized
to a single ISP -- or to a group of confederated ISPs (e.g., see RFC
1955) -- behave differently than today's BGP tables, and will result in
local tunnel routing tables (from the point-of-view of that local ISP)
that are substantially smaller than the Internet DNS table. Routes
entirely supported locally by that ISP (or the confederation of ISPs to
which it belongs) need not be tunneled by that ISP. However, this is not
the case for remote ISPs which will need to access the
Local-ISP-supported ASes through tunneling. But that fact need not
effect the tunnel address calculations of the local ISP itself,
simplifying those local calculations.

2) It is conceivable that ISPs may receive numerous requests to connect
enterprises that internally use private addresses (e.g., Net10). That
ISP will negotiate with those enterprises how this will be accomplished.
They will also support many home users and many small businesses. The
public addressing of these entities will use PA addresses from that ISP,
which will be highly aggregated. That aggregation could be retained in
the Internet DNS entries if the tunnel endpoints provided by that ISP
similarly permit aggregation (i.e., are deeper within the ISP than at
the PE-CE boundaries to the supported ASes).

The LISP approach also empowers us end users. For example, my coworkers
and I have been telling various IETF mail lists for the past decade that
it is non-negotiable that we will solely accept PI addresses whether or
not the IETF permits a PA-PI address distinction to exist or not. The
world's other largest companies and governments are almost certainly
going to make similar demands. It simply doesn't matter what the IETF
thinks about this (and thus the IETF needs to just deal with it, which
it recently appears to be doing) because it is unlikely that ISPs will
lose the business of their largest customers over their internal
addressing requirements (i.e., re-addressing is very expensive with no
attendant business gain). Worse comes to worse, we will just decree that
we are also ISPs because of our huge sizes. LISP resolves this dispute
by making internal addressing irrelevant to anybody but the corporation
(or government or whatever) itself and the ISPs that support it.

LISP therefore promises that the shadow of IP addressing will diminish
from business and Internet scaling, which is A Good Thing. Equally
important, it also promises that the IETF will again have a coherent and
common Internet architecture vision, which is a philosophical grounding
that many of us have been longing for for quite some time.

-----Original Message-----
From: Peter Sherbin [mailto:[email-masked]] 
Sent: Friday, March 30, 2007 6:32 AM
To: Fleischman, Eric; [email-masked]; [email-masked]
Subject: RE: [RAM] Incremental Deployment of LISP

Speaking as a (large) ISP I hear a client wanting a sort of a private
network with a kind of a class of service at price of a shared best
effort bandwidth. TANSTAFL :)

Thanks,

Peter
--- "Fleischman, Eric" <[email-masked]> wrote:

> >without
> incorrectly) expect the ISPs supporting us to do, I believe that this 
> is not a problem for the following reason:
> 
> process that is not done overnight, to say the least. Each ISP 
> provides ingress and egress paths to the Internet for us. The 
> disproportionate percentage of our traffic goes to a finite number 
> (let's say a few hundred -- but this number is not relevant) of remote

> ASes via a small set of ISP-provided routers that are connected to a 
> small-set of POP routers that we provide. These ISP-provided routers 
> will not be looking up DNS entries at any point because the latency 
> involved with DNS lookups could not support the very high data rates 
> that they have committed to support in their business agreements with 
> us. For this reason, I expect that the ISPs will periodically map the 
> Remote AS-to Remote-Internet-tunnel-endpoint relationships contained 
> in the then current DNS tables (from the perspective of their position

> within the Internet (e.g., in regards to load-balancing and 
> multi-homing and traffic engineering connections in accordance with 
> our agreements
> together)) via a mechanism of their choice. This calculation will 
> create a database that they will then load into an appropriate cache 
> within their POP routers. This cache will contain the calculations for

> of our traffic will always remain limited to the few hundred remote 
> ASes that we primarily deal with. I further presume that only deltas

________________________________________________________________________
____________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 30 Mar 2007 11:07:59 -0700

On Mar 30, 2007, at 10:49 AM, Fleischman, Eric wrote:

> enterprises that internally use private addresses (e.g., Net10).

Perhaps I'm wrong, but it seems to me that this type of connectivity  
isn't generally handled by SPs, but is handled by the enterprises  
themselves.

RFC1918 collision is certainly an issue in these scenarios, often  
resulting in bidirectional NATting and other ugliness.

In your view, does LISP or another solution in this general space  
apply only to the Internet, and only to ISP-to-customer  
communications?  Someone else earlier mentioned MANET, what about  
disintermediation in general?

                       -- Duong Van Ngo

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Mar 2007 11:13:20 -0700

> disintermediation in general?

Just as an aside, if we want to talk about a solution that
incorporates LISP-like concepts, DNS mapping, and MANET for
intra-site navigations then we have to put IPvLX and its
companion documents (including ISATAP) on the table; see:

  http://ipvlx.net

(I can't give a timeframe, but this work is due to be updated.)

Thanks - Fred

---

From: Peter Sherbin <[email-masked]>
Date: Fri, 30 Mar 2007 11:52:34 -0700 (PDT)

Agreed with what you are saying, in particular on PI (ISP hat's off).

> behave differently than today's BGP tables, and will result in
> local tunnel routing tables

IMO standards aim at making things just work e2e without a need for any intervention
including local fine-tuning aka customization. LISP seems to prolong the original
design, which might be OK for the short term.

Thanks,
Peter

---

From: "Fleischman, Eric" <[email-masked]>
Date: Fri, 30 Mar 2007 17:48:28 -0700

My apologies to the list!! My last posting contained a very poorly
written paragraph that mis-communicated some important points. This
posting seeks to correct that by explaining why our historic IPv6 target
architecture inadvertently assumes a business model that wars against
the successful deployment of an IPv6 Internet and that approaches such
as LISP correct that schizophrenia, increasing the probability of a
successful Internet deployment outcome. 

In RFC 1687 (which was an official Boeing corporate position of that
era, unlike all of my recent postings, which are solely my own personal
opinions and sought to generically represent the large end user) I
sought to explain why the natural inclination of the large end user
corporation will be to not deploy IPv6 (then called IPng) unless a
compelling business reason to adopt it arises. Should such a business
reason arise, the natural tendency will be to deploy IPv6 in the most
minimal manner possible. The exception, of course, is if IPv6 became
associated with a killer app. Because this is yet to occur, IPv6 remains
a "hard sell" to the end user.

A key part of the reason for this is that the motivations underlying the
creation of IPv6 reflect the concerns of our ISP population and those
concerns are completely hidden from the end user. Had the IETF's ISPs
not told us that there is an Internet scaling problem with BGP, we end
users would not have been aware of that fact. Therefore, IPv6 is itself
a solution to the ISP's problems into which the end user has no
visibility -- nor is there any capability within IPv6 to encourage the
end user to want to deploy IPv6 on its own merits.

To make matters worse, the IETF's original position for IPv6 addresses
was to solely permit PA addresses, requiring the end users to have
addresses that were dependent upon ISPs. This is backwards: a law of
economics is that businesses support the desires of their customers,
rather than the customers supporting the desires of their vendors!! IPv6
also requires the large end users to be willing to needlessly pay a very
expensive re-addressing penalty to deploy IPv6 that does not exist for
IPv4 (i.e., assuming they had pre-CIDR IPv4 addresses which are
inherently PI). Thus, the business model underlying an IPv6-oriented
Internet contains very strong incentives to ensure that that an IPv6
deployment will not occur.

LISP corrects this. The business model assumed by LISP is not
self-defeating and therefore LISP has a substantially better chance of
actually being successfully deployed than any model seriously
entertained by the IETF since I joined our community in 1992. This is
because LISP restricts the Internet solution to the sole community that
has any visibility into that problem. The only thing that LISP requires
of the end user is to coherently deploy an IP variant -- something the
end user is inherently motivated to do. Therefore, LISP is win-win -- it
does not demand a community having no awareness of a problem to
sacrificially bear the expense of fixing that problem.

Appeals to altruism are effective to the extent of self-awareness and
economics. It is unreasonable to expect a community to be motivated by
issues it does not know exist. For example, why isn't the Internet
community altruistically interested in helping the petroleum or
electrical industries? After all, we directly rely upon their products.
For the same reason, only the Internet community could be expected to be
altruistically motivated to help solve the Internet's problems.

>The LISP approach also empowers us end users. For example, my coworkers
and 
>I have been telling various IETF mail lists for the past decade that it
is 
>non-negotiable that we will solely accept PI addresses whether or not
the 
>IETF permits a PA-PI address distinction to exist or not. The world's
other 
>largest companies and governments are almost certainly going to make
similar 
>demands. It simply doesn't matter what the IETF thinks about this (and
thus 
>the IETF needs to just deal with it, which it recently appears to be
doing) 
>because it is unlikely that ISPs will lose the business of their
largest 
>customers over their internal addressing requirements (i.e.,
re-addressing 
>is very expensive with no attendant business gain). Worse comes to
worse, 
>we will just decree that we are also ISPs because of our huge sizes.
LISP 
>resolves this dispute by making internal addressing irrelevant to
anybody 
>but the corporation (or government or whatever) itself and the ISPs
that support it.

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 30 Mar 2007 18:03:33 -0700

On Mar 30, 2007, at 5:48 PM, Fleischman, Eric wrote:

> Should such a business

Address exhaustion due to supply-chain, proliferation of spimes, etc.  
will probably become a real issue at some point, however.

Do you believe that a LISP-like solution is also suitable for the  
'Internet of Things'?

Does a LISP-like solution retain the concept of a single global  
Internet?  If not, have we 'outgrown' that concept due to various  
technical, business, and political reasons?

Does a LISP-like solution lend itself to MANET?  Is MANET at some  
point in the foreseeable future going to become the norm, with  
complete disintermediation between what we now think of as SPs and  
customers?

Is a LISP-like solution the desired end-state, or should it be viewed  
as more of a transitional mechanism to Something Else?

                       -- Duong Van Ngo