[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] Origins of LISP PTRs / Ivip OITRDs

Hi Vince,

In your recent message "Re: [RRG] IPv4/6/ngng or IPv4-map-encap then
IPngng" you discussed the origins of the LISP "Proxy Tunnel Router"
concept.

> I don't really want to wade into this debate but I want to set the record
> straight on one point:
> 
>> 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".)
> 
> 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.

OK - what I wrote was in terms of the public discussions.

On the RAM list on 2007-06-20:

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

you quoted an internal Cisco list message from 2007-04-04 in which
point 6 does describe the essential principles of LISP's "Proxy
Tunnel Routers", which are the same as Ivip's OITRDs ("Open ITRs in
the DFZ", previously "Anycast ITRs in the core" which as your
colleagues pointed out involved an incorrect use of "anycast".)

Five days earlier my message of 2007-06-15 (2007-06-14 in the archives):

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

seems to be the first public mention of this principle:

  ViP uses Anycast to provide multiple redundant paths within
  the BGP system for packets to find their way to an ITR.

That was within 24 hours of me thinking of the idea.  In later
messages I went into greater detail about how a single advertised
prefix could cover the address space used for many end-user networks
 - so the impact on the BGP system would be vastly smaller than the
current arrangement.

I had an Internet draft a month later and Ivip and this particular
concept was largely ignored by the LISP team.  I recall trying to
argue the merits of the concept on the RAM list and finding Dino and
others criticising it.

It is not surprising the concept was thought of earlier by the LISP
team, but I am perplexed that the LISP team ignored or criticised my
version of it, and took so long to adopt it as PTRs in early
December 2007.  It is a simple concept and is absolutely crucial to
the adoption of any map-encap scheme such as LISP, Ivip or whatever.

During one of the early December meetings, Tony Li relayed my
question about the origins of PTRs to the LISP team, and I recall
someone responding, in part, "Not invented here".

My point is not so much to say "I invented this" but to say that I
think LISP would be a better proposal if you accepted critiques and
suggestions from other people such as myself sooner.  I also think
LISP would be improved if you took the time to understand and
critique alternative proposals, particularly Ivip, and took whatever
was useful to you from such proposals.

From June to December, I was unable to interest the LISP folks in
the concept of ITRs advertising in the DFZ, where the prefix covers
the EID/micronets of large numbers of end-user networks - except
perhaps for one exchange with Eliot Lear.

So far the LISP team seems uninterested in the use of map-encap for
mobility or for improving utilisation of IPv4 space.  You are
welcome to all I wrote about this and to my suggestions for solving
the PMTUD problem too.

I urge you to make a central LISP page so people can easily find the
latest news, the latest IDs, presentations etc.  At present, the
best guide to your proposal seems to be my page:

  http://www.firstpr.com.au/ip/ivip/lisp-links/

While there is much more work to do on Ivip IDs, there is now enough
detail about the overall architecture, and the fast-push mapping
distribution system for someone to make substantial critiques.  I
have done this favour for the other schemes and would appreciate
someone doing the same for mine.  I know the Ivip-arch ID is hard to
navigate - forget the earlier parts of that for now and concentrate on:

  http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf
  http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00
  http://www.firstpr.com.au/ip/ivip/pmtud-frag/
  http://psg.com/lists/rrg/2008/msg01158.html (OITRD business case.)

For mobility, there is:

  http://www.firstpr.com.au/ip/ivip/#mobile

and there is a draft paper I can send to anyone who is interested
which better explains the TTR mobility extensions for map-encap schemes.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com 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