Subject: [RRG] IPv4/6/ngng or IPv4-map-encap then IPngng

From: Robin Whittle <[email-masked]>
Date: Thu, 12 Jun 2008 14:32:48 +1000

Hi David,

I haven't been able to reply to all the interesting RRG messages,
but here goes for this one, in the "Re: [RRG] GSE?" thread:

> More seriously, the reality is that to date, IPv6 has seen
> essentially zero use so ripping it out and replacing it with
> something else would not operationally impact significant numbers
> of people.

I agree.

> However, with that said, I would agree that this isn't so much a
> technical issue as a political one.  

Yes, in terms of gathering the troops with a common purpose which
will actually prepare the new planet for billions of non-technical
colonists, in a short enough time that they don't become toast on
the old planet.

> From my perspective, I have always felt we have 3 options:
> 
> 1) IPv4 + NAT, more NAT, and forever NAT 
>
> 2) IPv6 + some new network element (ITR/ETR, a new layer,
>    a new transport protocol, etc.)
>
> 3) IPngng
> 
> As far as I can tell, proposals to "Do it Right" are option (3)
> since they will require pretty much the same level of effort in
> terms of redeploying protocol stacks and modifying applications
> (I'd argue that applications knowing address structure and
> keeping copies of addresses in their data space is an example of
> how to "Do it Wrong").
> 
> I'm hoping we can get by with option (2).
> 
> I suspect we're going to end up with option (1).

OK.  What about:

  3a)  Map-encap for IPv4.

which gives us more time to think properly about:

  3b)  IPngng

I have my own ideas about that, since it needs to have a much better
migration plan than IPv6 did.

>> NAT-PT has been buried
> 
> Please don't take the actions of the IETF as reflections on
> reality.  

OK, but aren't we busying ourselves here making a mere
recommendation to this outfit who are so disconnected from reality?

Maybe so . . .   IPv6 was never attractive enough to folks to
actually adopt, let alone adopt to the exclusion of IPv4.  I am
convinced there is enough scope for NAT and efficient use of IPv4 -
especially with map-encap - to keep IPv4 going indefinitely.  That
is not what I want - because it is easy to imagine something better.
 But without something more immediately useful than IPv6, and with a
much better transition arrangement, I think the population en-masse
is going to stay *together* on Planet IPv4 no matter how hot it gets.

The big thing about the Internet is that it is everyone together.
On IPv6 it is rather lonely and misses the point - until everyone
else moves too.

> In all of the recent IPv6-only 'experiments' that have
> taken place at operations meetings, the IETF, and RIR meetings,
> _all_ of them used NAT-PT.  Some reasonably successfully.  Like
> NAT itself, NAT-PT meets a functional need and the market will
> make its own decisions as to whether it lives or dies, regardless
> of what folks at the IETF might say.

Still, if NAT-PT hasn't been used for more than a few tests with the
IPv6 faithful - that is is it not suitable for Comcast etc. to sell
IPv6 only services to the mass market - and if has been officially
junked by the IETF, then I say that IPv6 migration arrangements are
a shambles.

Below is a wild and crazy IPngng idea.

  - Robin

<cue: eye-rolling & exasperation from those who have seen too
      much similar stuff before>

Since we are talking revolution, what about keeping BGP as it is,
doing Ivip-like map-encap with TTR mobility for IPv4.  Later, we
create a new version of IP - say IPv99 (in homage to the Secret
Agent and because no-one will need a later version . . ) with 64 bit
addresses.

This is intended to offer a much cleaner transition mechanism for
applications and end-users than IPv4 offers.  There are no
dual-stack machines - the IPv99 stack handles IPv4 as a natural
subset of its operations.  IPv99 applications can always talk
directly to IPv4 hosts, but this is just a sketch and there are many
other things to consider.  Probably IPv4 connectivity to IPv99 hosts
would be limited.

An IPv99 address such as:

   xx xx xx xx 00 00 00 00 (hex)

represents the existing IPv4 address xx xx xx xx.

Packets addressed from IPv99 hosts to such addresses go to IPv4
hosts, either by IPv4 packets directly (the sending host has IPv4
and IPv99 connectivity) or via IPv99 and then to some ALG or
whatever which sends them as IPv4 packets and handles the returning
packets too.

Packets with addresses:

   xx xx xx xx 00 00 00 01
to xx xx xx xx FF FF FF FF

are IPv99 native addresses.

Ultimately there may be a native IPv99 backbone, and there would be
a native IPv99 header, of course.

In the meantime, all IPv99 hosts in the above address range can be
reached via a router at the IPv4 address xx xx xx xx.  This includes
especially if this xx xx xx xx address is handled by map-encap.

(For better or worse, overall IPv99 address allocation is therefore
based on existing IPv4 allocation.  Good because no new mechanisms
are needed and because each IP address gives a potentially vast
number of IPv99 addresses at a site.  Bad, probably, because it
imports stuff which may be suboptimal forever into IPv99.)

So you could have 2^32 uniquely addressable IPv99 hosts reachable
over the IPv4 Internet, via each IPv4 address, including especially
having them reachable via a portable, multihomable and potentially
mobile single IPv4 address.  There are PMTU things to sort out with
all this, but that needs to be sorted anyway as part of the IPv4
map-encap system.

All IPv99 hosts have a new stack, which translates between the
outside world and the IPv99 API for IPv99 applications.  Maybe an
IPv99 machine can run unmodified IPv4 applications via some
adaptation layer which enables the unmodified IPv4 apps to talk
through the actual IPv99 stack to IPv4 addresses only.  (This would
involve some ALG or NAT-like device with IPv4 address space.)

Packets sent to and from IPv4 addresses within the IPv99 address
space are sent with IPv4 headers and IPv99 addressed packets are
sent with IPv99 headers.  How the packets get to their destination
depends on what other IPv99 networks the host has a native
connection to and whether it has an actual IPv4 service, or reaches
IPv4 hosts via the IPv99 service.

Applications would require something of a rewrite, but could still
do IPv4 things with the IPv4 Internet, so perhaps it is not really a
dual-stack system.

To what degree the IPv99 to IPv99 communications would differ from
existing IPv4 protocols I am not sure, but I would want to add some
kind of PMTU discovery message which could test the MTU along a
bunch of routers without actually being very long itself.  However,
to make that happen over the existing IPv4 DFZ would require
significant changes to those routers.  I am more thinking about an
IPv99 future, with a more elegant PMTU handling arrangement in all
its routers than is the case with IPv4 or IPv6.

The key thing is to make a new protocol which sees the IPv4 world as
a special subset of its own space and protocols, and which uses the
IPv4 network with map-encap to avoid the need, initially, for a new
backbone.  The robust multihoming, portability and potentially
mobility of map-encap makes this much more attractive, I think, than
relying on the existing /24 limits of BGP to slice up the IPv4 space
as the basis for a lasting 32 bit extension such as this.

I am not sure if there have been other attempts to use a robust,
finely slicing, map-encap IPv4 infrastructure as the basis for
IPngng flights of fancy such as this.

There could be hundreds of millions of separate IPv99 networks
accessible reliably over IPv4, without much further burden on the
IPv4 BGP control plane.

I still think 128 bits of address is 64 too many.  They are long to
store and process, since 64 bits is a perfectly good length for a
CPU register.  128 bits bloats the headers excessively, especially
for VoIP packets and doubly so for map-encap IPv6.

I am not sure whether map-encap would be used within the native
IPv99 network.  A native IPv99 network would probably need its own
map-encap system for multihoming, TE and portability, so it might as
well be used for mobility too.  How that would blend with or be
based on the original IPv4 map-encap system, I am not sure.  Would
it slice finer than the left-most 32 bits?

(Maybe a GSE-souped-up IPv6 wouldn't need map-encap for multihoming
and portability.  It would need it for TTR-style mobility.  I am not
sure how GSE-IPv6 would do TE.)

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Per Heldal <[email-masked]>
Date: Thu, 12 Jun 2008 11:24:31 +0200

Efforts to extend the life of v4 may fall on one simple issue. What if
we can't re-claim or reuse enough of the previously assigned
address-blocks to meet the markets demand for growth at the customer
edge? 

We may know how much of the space isn't announced to the DFZ or
otherwise have potential for reuse, but there's no data to support that
this actually will happen, even if all and any constraints on routing
were lifted.

//per

---

From: Robin Whittle <[email-masked]>
Date: Thu, 12 Jun 2008 19:49:44 +1000

Hi Per,

You wrote:

> Efforts to extend the life of v4 may fall on one simple issue.
> What if we can't re-claim or reuse enough of the previously
> assigned address-blocks to meet the markets demand for growth at
> the customer edge?

I agree.

I can't say for sure what will happen.  I believe there are good
reasons to believe that commercial pressures will drive the adoption
of a finer slicing and better management technique - map-encap - to
make it technically possible without worsening the routing scaling
problem.

One that happens, I figure money and IP addresses will change hands
quite merrily.

> otherwise have potential for reuse, but there's no data to 
> support that this actually will happen, even if all and any
> constraints on routing were lifted.

"Data" about the future is hard to come by!

I have no data on how much address space existing holders would give
up, but if the price was right, I am sure that quite a lot of space
could be found.  The idea is to find it in largish chunks, so that
chunk can be a single advertised prefix split up among many -
hundreds or maybe thousands - of end-user networks.

I am not sure of the morality or legality of those with space now
selling it.  I am just saying that if there are folks clamouring for
it with money to pay for it, then this is a good motivation for
those with sparsely used space to consolidate their usage into a
smaller patch and to vacate the rest.  Maybe the vacant space goes
back to the RIR, or maybe they sell it or rent it.

I just think that at every point in time for a long while to come,
it will be easier and more profitable to use IPv4 more intensively
than try to get paying home and SOHO customers (or end-user
networks) to do without IPv4 addresses and rely on IPv6 only -
albeit with some IPv4 space for ALGs, NAT-PT, NAT64 etc.

I wrote more on this:

  http://lists.arin.net/pipermail/arin-ppml/2008-June/011005.html

and have discussed this notion on the RRG in previous months.  I am
not sure I convinced anyone, but it looks pretty likely to me.

 - Robin

---

From: Per Heldal <[email-masked]>
Date: Thu, 12 Jun 2008 12:12:06 +0200

> "Data" about the future is hard to come by!

Any company and/or organisation today is expected to analyse the
behaviour of their market and client-base. How hard is it for the
internet registries to ask a statistically significant selection of
their clients (LIRs) and known legacy-allocation holders if they're
willing to give up some of their allocated blocks, how much of it, and
on which conditions?

They haven't even tried, which speaks volumes about how realistic they
consider this to be. In this also consider that the registries policies
and work is directed by those exact companies and organisations that
depend on a viable path for future growth.

//per

---

From: Robin Whittle <[email-masked]>
Date: Thu, 12 Jun 2008 20:58:29 +1000

Hi again Per,

You wrote:

> internet registries to ask a statistically significant selection
> of their clients (LIRs) and known legacy-allocation holders if
> they're willing to give up some of their allocated blocks, how
> much of it, and on which conditions?

The scenario I am proposing depends to a large extent on map-encap.
 It could still happen to a limited extent by creating more and more
BGP advertised prefixes, but that will be resisted because it would
unfairly burden all DFZ router operators.

For the RIRs to seriously consider the possibility I am suggesting,
they would need to have a good understanding of the possibilities of
map-encap schemes.  Yet these schemes - with the exception of the
LISP prototype code - are vapourware and hardly known outside the
RRG.  Even within the RRG not many people have much faith in them,
and each of us map-encap developers has less faith in the other
systems than in our own!

I used to think I was being rather optimistic and imaginative with
all this, but Tony's apparent desire to convert IPv6 to GSE in time
to save the masses on Planet IPv4 is no less ambitious.

As fresh space becomes harder and harder to get, there will be an
increasing demand amongst end-user networks and ISPs for any space
they can get.  I think ISPs need large slabs, but I think many
end-user networks could be happy with relatively small chunks of
space, including especially fractions of a /24.

I imagine there would be a curved relationship between the price per
IP address and the number of IP addresses in the prefix which
end-users want.

I think you could find hundreds of thousands of end-users who would
pay, say $20 a year per portable, multihomable IP address, for small
amounts such as 1, 2, 8, 32 or so.

I guess ISPs want /20s and shorter, and don't want to pay $80k a
year for a /20.

I imagine there are significant number of ISPs and end-user networks
with excess space - space they are either not using at all, or space
they could do without if they moved some of their hosts to a
fraction of the space they currently have.  They wouldn't want to do
this to the point of feeling too hemmed in.

Without a map-encap system there is no way of renting hundreds of
thousands of end-user networks smallish chunks of PI space.  With a
map-encap system, it becomes easy - and it would be largely out of
the hands of the RIRs.  Whoever has the prefix allocated (assigned?)
to them by the RIR can decide to put it into the map-encap system
and split it up amongst potentially thousands of paying customers.

I guess that this new use of address space would have to be agreed
to by the RIRs.  There should be no problem with this, because any
such usage serves many more end-users than could be served in a
scalable manner with that prefix without map-encap, so it would be
considered a progressive, desirable, way to use the space.

In this way, the map-encap system enables the provision of a highly
valuable resource - portable, multihomable IPv4 space - in the small
chunks which (I think) large numbers of customers want and will pay
a high fee for.  This is a high price per IP address but low per
customer.

It is easy to see where that would lead - a strong economic
incentive to the tune of $10 or $20 a year for people sitting on
sparsely used address space to clear themselves out of at least some
of it, and rent, sell or whatever it to someone who will make much
more profitable use from it by splitting it up with map-encap.

Also, since the map-encap scheme enables all end-user networks to
get portable multihomable space in small chunks (as well as large
ones) then there is a lot less justification for existing PI space
users holding on to large sparsely used blocks of space in case they
might need it one day.

It would not be quite so elegant to have a bunch of smaller prefixes
for a largish end-user network as to have a single large one.
However, each such map-encap prefix could be separately multihomed
and used at any of the end-user's sites.  Each could be split
arbitrarily finely, down to individual IP addresses, each mapped to
a different ETR, if that is what the end-user wanted to do with this
space.

The conventional convenience and simple aesthetics of having one
largish prefix per end-user network won't be a valid justification
for sitting on largely unused space as long as there is a global
shortage of space and lots of smaller end-user networks are
clamouring to spend $10 a year or more per IPv4 address.

In addition, there is a potential market for TTR-mobility - where
the laptop or cellphone is generally fine with a single IPv4
address.  That could be a huge market, again driving up the value of
any IPv4 space which can be put into the map-encap system as one
largish block, and split up amongst many customers.

> They haven't even tried, which speaks volumes about how realistic
> they consider this to be. 

Yes, but to be fair, this map-encap stuff is revolutionary
vapourware.  Even within the RRG, it may not be a majority view that
it should be attempted in IPv4 at all.

> In this also consider that the
> registries policies and work is directed by those exact companies
> and organisations that depend on a viable path for future growth.

I guess in a few years time when someone demonstrates a reasonably
practical map-encap system - or builds one like Ivip primarily to
run a TTR-based global mobility service - that the RIRs, ISPs etc.
will think differently.

 - Robin

---

From: Per Heldal <[email-masked]>
Date: Thu, 12 Jun 2008 13:28:40 +0200

On Thu, 2008-06-12 at 20:58 +1000, Robin Whittle wrote:
> map-encap schemes. 

>From where do you get the idea that these groups are so completely
disconnected? There's always been disputes between ISP-engineers with a
preference for practical working solutions and idealist scientists.
Still, leading engineers in the provider industry who are active
participants in governance-communities are closely following these
developments as subscribers on these lists. Your assumptions of
ignorance is offending a lot of people.

>  Yet these schemes - with the exception of the

If the RIR communities are so ignorant then why have such solutions been
discussed both on and off-stage at community conferences for years?

[snip]

> amounts such as 1, 2, 8, 32 or so.

A problem with this is that micro-allocations only make up a small
portion of the annual global consumption. If the big consumers are
pushed into such prices/address you'll very soon see considerable
investments going towards alternative solutions.

//per

---

From: Robin Whittle <[email-masked]>
Date: Thu, 12 Jun 2008 23:14:41 +1000

Hi Per,

You wrote:

>> For the RIRs to seriously consider the possibility I am
>> suggesting, they would need to have a good understanding of the
>> possibilities of map-encap schemes.
> 
> From where do you get the idea that these groups are so
> completely disconnected? There's always been disputes between
> ISP-engineers with a preference for practical working solutions
> and idealist scientists. Still, leading engineers in the provider
> industry who are active participants in governance-communities
> are closely following these developments as subscribers on these
> lists. Your assumptions of ignorance is offending a lot of
> people.

I don't mean to offend anyone.

I don't know what the membership of the RRG list is.  Mailing lists
are weird in that there could be hundreds of people reading
everything intently and even discussing it privately amongst
themselves.  If  they never write to the list, then those who do
write might never know they exist.

My impression is that only a subset of active RRG members support
map-encap at all.  Of them few if any have expressed serious support
for Ivip.  I have collaborated with a lurker on a paper about
mobility - yet to be finalised - so I know at least one RRG member
has confidence in my proposal.

Your direct knowledge of who reads this list is presumably better
than my lack of knowledge.  If there are folks keeping up with all
this, and who think IPv4 map-encap is worth considering, then I
suggest that now would be a good time to de-lurk and join the debate.

>> Yet these schemes - with the exception of the LISP prototype
>> code - are vapourware and hardly known outside the RRG.  Even
>> within the RRG not many people have much faith in them, and
>> each of us map-encap developers has less faith in the other 
>> systems than in our own!
> 
> If the RIR communities are so ignorant then why have such
> solutions been discussed both on and off-stage at community
> conferences for years?

While map-encap in principle has been suggested for years, as far as
I know, I was the first to propose a form of map-encap which
supported backwards compatibility for full connectivity (with
portability and multihoming) for packets to and from non-upgraded
networks.  In proposing this, I think I was the first to show that
one could create independent address prefixes for hundreds or
thousands of end-user networks, each portable and multihomable,
within a single shorter prefix which constituted a single BGP
advertised prefix.

That was my way of improving LISP, to create the beginnings of my
Ivip proposal, on 2007-06-15:

  http://www.ietf.org/mail-archive/web/ram/current/msg01518.html

Before that LISP had no way of being introduced with multihoming of
communications from non-upgraded networks.  (Late last year LISP
became able to do this, by adopting Proxy Tunnel Routers which do
the same job as my poorly named "anycast ITRs in the core" - now
"Open ITRs in the DFZ".)

The way I am suggesting IPv4 space be finely sliced up and used as
PI space for large numbers of end-user networks, without worsening
the routing scaling problem, AFAIK has its roots in my proposal.
Maybe the LISP team don't think their system could or should be used
this way, but I think it can and should be.

Maybe such proposals have been floating around for longer than this,
but it was my impression they are about a year old.  Maybe lots of
RIR - ISP people are totally up to speed on all this.  I hope so.

>> I imagine there would be a curved relationship between the
>> price per IP address and the number of IP addresses in the
>> prefix which end-users want.
>> 
>> I think you could find hundreds of thousands of end-users who
>> would pay, say $20 a year per portable, multihomable IP
>> address, for small amounts such as 1, 2, 8, 32 or so.
> 
> A problem with this is that micro-allocations only make up a
> small portion of the annual global consumption. If the big
> consumers are pushed into such prices/address you'll very soon
> see considerable investments going towards alternative solutions.

I agree that if the big ISPs can't get the space they need they will
be highly motivated to trying to figure out how to sell IPv6-only
services to home and SOHO customers, each of whom chew an IPv4
address each at present.

My understanding is that the routing scaling problem is driven
largely by end-user networks needing PI space for multihoming and
TE.  As far as I know, a lot of those end-user networks could get by
happily with less space than they currently get from RIRs, if a
map-encap system was working as I intend.  Then, there are a much
larger number of other end-user networks who currently don't have
the resources to get BGP-managed PI space who could also get these
smaller, cheaper, scalable slices of map-encap managed PI space.

Map-encap provides a drastically better form of management for PI
space than the current BGP system, which for various reasons which
are unlikely to change doesn't slice up space into smaller chunks
than 256 IP addresses.

Map-encap provides much finer control of space, without burdening
the BGP control plane - and so will surely enable a much better
utilization of IPv4 space.

I can't quantify this.

However, given the apparently low actual usage rates of IPv4
addresses, such as less than less than 20% on most advertised prefixes:

http://www.firstpr.com.au/ip/host-density-per-prefix/
http://www.firstpr.com.au/ip/host-density-per-prefix/all-graphs/
http://www.isi.edu/~johnh/PAPERS/Heidemann08a.pdf

even allowing for ping probes seriously under counting actual usage,
and with 3.7B addresses which could be advertised when 1.7B are
currently advertised, I think there is tremendous scope for more
IPv4 addresses actually being used in the next 10 to 15 years.

 - Robin

---

From: Tom Vest <[email-masked]>
Date: Thu, 12 Jun 2008 13:15:52 -0400

> and each of us map-encap developers has less faith in the other

I can attest that this is not accurate. A wide variety of future  
scenarios are and have been considered by the RIRs, including ones  
involving map & encap. However, if the primary function of the address  
resource administration system is to preserve over time the essential  
technical features/benefits for which the addressing system is  
designed (ala CIDR:RIR), then there's only so much that can be done  
before the addressing system and its goals are specified.

In the IPv4 context, the mere existence of (even abundant) quantities  
of public address space may be necessary but it is not sufficient to  
sustain the availability to those resources for future growth. Given  
the effort that was put into CIDR precisely to increase the carrying  
capacity of the existing routing and addressing system, it seems  
pretty clear that continued, unimpeded growth was a goal. But that  
didn't answer the question of what (else) causes or contributes to, or  
impedes or prevents growth. Is the goal of growth advanced by rigorous  
address request verification requirements, which help to conserve the  
address pool for as long as possible, or do such requirements impede  
growth by imposing burdensome administrative costs on current and  
aspiring operators? Is it advanced by contractual commitments and  
enforcement mechanisms that could bring idled address resource back  
into the pool for redistribution, or do those create too much  
controversy and overhead? Finally, in an environment where Internet  
services are being developed and delivered on a commercial basis, it's  
useful to remember that (one's own) growth is just one of many  
alternative strategies for achieving the primary goal, profitability;  
sometimes non-growth of current or potential competitors may be just  
as appealing.

Even if the apparent idleness of lots of routed address space is not  
just an artifact of measurement, it's not immediately obvious which  
among these and/or other factors is to blame -- not to me anyway.

I believe that the RIRs have done their best to facilitate the goal of  
growth despite the continuing ambiguity surrounding all of these  
questions. For any successor addressing system -- map & encap-based or  
otherwise -- to be approved, implemented, and judged successful over  
time, it's probably worthwhile to consider these questions up-front  
rather than waiting for them to answer themselves -- because sometimes  
they don't  ;-)

Speaking for myself only,

Tom Vest
RIPE NCC Science Group

---

From: David Conrad <[email-masked]>
Date: Thu, 12 Jun 2008 08:39:52 -0700

Robin,

> which gives us more time to think properly about:

My understanding of the situation is that the immediate problem with  
IPv4 isn't (I'm told) routing scalability, but rather addressable end  
points.  As more IPv4 end points are put into play, it will exacerbate  
the routing scalability problem, but we've been there before and the  
tools we used then (filtering) will undoubtedly be used again.  As  
such, (3a) solves a different problem than the one that is likely to  
drive increased IPv6 utilization.

> recommendation to this outfit who are so disconnected from reality?

My hope, at least, is that our recommendation will allow for at least  
some reconnection with reality.

> I am
> especially with map-encap - to keep IPv4 going indefinitely.

Indeed.  However, if you're doing NAT, what's the point of doing map- 
encap?  As others have noted, NAT effectively creates a locator/ 
identifier split, allowing the public address to be (relatively)  
easily renumbered without impacting the RFC 1918 identifiers inside  
the NAT boundary.

> IPv6 faithful

I suspect this is because IPv6 itself hasn't been used for more than a  
few tests with the IPv6 faithful.

> Since we are talking revolution ...
[much elided not because there is anything wrong with it, but because  
I think it something of this nature should be put into draft form]

I remain unconvinced that a revolution is actually realistic.  I never  
got an answer to my question regarding what people think is "Doing it  
Right" or even what is "Doing it Wrong", but if you make the  
assumption that having something that is actually used is a part of  
"Doing it Right", the _only_ way we're going to get their (at least in  
my lifetime) is by evolutionary incremental change.

However, with all that said, one advantage of map-encap (done right)  
is that the stuff that is mapped and encapped can be fixed for all  
eternity while the stuff that transports the encapped stuff can be  
changed.  As such, fixing something that has a reasonable chance of  
being scalable for all eternity (e.g., 128 bits) seems like a  
reasonable thing to do.

Regards,
-drc

---

From: Vince Fuller <[email-masked]>
Date: Wed, 18 Jun 2008 15:55:33 -0700

I don't really want to wade into this debate but I want to set the record

> the same job as my poorly named "anycast ITRs in the core" - now

Not correct. The first documentation of what was later fleshed-out as LISP+ALT
and LISP PTRs (proxy tunnel routers) occurred on a Cisco-internal mailing
list in April, 2007. This discussion was later opened to the RAM list in
June, 2007 (see attached email message, which includes both references).
The terminology has changed somewhat since these discussions by the basic
ideas remain the same.

The concepts originated during a lunch conversation at IETF-67 in November,
2006 but were not written down or propagated beyond the LISP co-authoers
until much later.

Just wanted to set the record straight.

	--Vince

---

From: Michael Meisel <[email-masked]>
Date: Thu, 19 Jun 2008 08:34:05 -0700

> 2006 but were not written down or propagated beyond the LISP co-authoers

Actually, I know of at least one earlier appearance of this concept: it 
was the central idea behind a 2005 SIGCOMM paper by Sylvia Ratnasamy, 
Scott Shenker, and Steven McCanne. Here is the link:

http://sigcomm.org/sigcomm2005/paper-RatShe.pdf

-Michael