http://tools.ietf.org/html/draft-irtf-rrg-recommendation

tools.ietf.org/html/draft-whittle-ivip-arch 

The 04 version of 2010-03-08 covers the new DRTM mapping system.

Also, a quick description of Ivip's network elements:


network-elements/ .

2010-03-26: please see the new description of the major parts of DRTM, with three detailed illustrations:


One of the illustrations is below.  This is the best way to understand the overview of DRTM - best to read it before reading the Internet Draft:

tools.ietf.org/html/draft-whittle-ivip-drtm-01

This is a new mapping system which I devised in Feb-March 2010, which is still real-time, but avoids the need for any server having the entire mapping database, and the need for ISPs and other networks with ITRs to run servers which gets real-time mapping feeds.  All the ITRs and query servers needed by ISPs etc. are fully caching devices. 

Significant adoption of scalable-routing-friendly SPI address space can be achieved with little or no ISP investment or involvement.  The initiative is taken by, and the investments are made by, organizations which need not be ISPs.  This requires only DITRs, QSAs and ETRs.  Compared to the original Ivip mapping distribution system, DRTM will be simpler for ISPs etc. to implement - and will be more robust. 

tools.ietf.org/html/draft-whittle-ivip-glossary-01

2010-03-06 - intended to help people come up to speed in this field.

tools.ietf.org/html/draft-whittle-ivip-etr-addr-forw-01

Revised 2010-01-13 with a minor update in 2010-07-08.  With a modest upgrade to all DFZ router FIBs, and by taking liberties with the IPv4 header, we can avoid encapsulation, its overhead and its Path MTU Discovery problems.  This is for the long-term future - it is not an essential part of Ivip for initial introduction. 

(The update is that perhaps it would be better to do the same thing, with a new protocol, with the same header length, and so use the Evil bit too, which would enable it to carry 31 bits of ETR address.)

TTR-Mobility.pdf

By Steve Russert and myself, August 2008, with minor revisions in January 2010.
More on this below: #mobile  TTR Mobility does not require a mapping change whenever the MN gains a new address or uses a new access network. 

msg07017.html (2010-06-22.)  A critique of all Core Edge Elimination (CEE, AKA Locator / Identity Separation) architectures.  (LISP is not such an architecture - it is a Core-Edge Separation architecture, as is Ivip and Fred Templin's IRON.)

On 2010-07-08, Dae Young Kim supported this viewpoint (msg07074.html), though I understand his ideal arrangement involves the IP address pointing to a node (host) rather than to one of its interfaces, as it does today.

msg07043.html (2010-06-26) 

Since I wrote this, which includes a lament on the lack of support for, or critiques of, Ivip, TTR Mobility and some other things I wrote, I have received some encouraging support.  I understand that Fred Templin's IRON architecture now uses some elements of TTR Mobility. 

Also, see Dae Young Kim's feedback mentioned above, and Tom Petch's support (msg06823 & msg07049)  for DRTM and my attempt to document the CEE/CES distinction - by stating he would like to see these written up as RFCs.  Unfortunately, I don't have time to do this in the foreseeable future, but perhaps someone will write up the CES/CEE material in an RFC.

I also made a page to record the most recent version of my arguments against hosts being expected to take on any more Routing and Addressing responsibilities, other than those really needed for mobile hosts:  RRG-2009/host-responsibilities/ .  See also a later account of this subject: msg07017.html (2010-06-22.)

In early December 2009 I discussed on the LISP WG list the inability of LISP-ALT to scale well - to provide short paths, with large numbers of EIDs, whilst also being structured for robustness against link and router failure.  The initial message is ALT structure, robustness and the long-path problem: www.ietf.org/mail-archive/web/lisp/current/msg01801.html .  This is a continuation of a critique I first made in late 2007, soon after ALT was announced.  Still no-one has proposed how these problems can be solved.  The attraction of ALT is now said, by some people, to be its ease of implementation (or perhaps design), since it is constructed using existing router functionality.  That's fine, but why bother making an ALT test network if ALT can't scale to billions of EIDs or whatever?  If ALT can't do this, LISP's future must be with some other mapping system - which should be developed and prototyped ASAP.  LISP has no other mapping system under development.  NERD was retired on 2009-11-17 (rrg/current/msg05274.html) and there has been CONS development since ALT was launched in late 2007.

The debate about whether LISP involves separate namespaces for EIDs and RLOCs has fired up again, on the LISP list:  namespace/  Also, I wrote a critique of the LISP Mobile I-D (draft-meyer-lisp-mn-00): http://www.ietf.org/mail-archive/web/lisp/current/msg00749.html.   See the #mobile section below for my suggestion that LISP use the TTR mobility approach rather than the "MN is its own ETR" approach of the recent Mobile LISP Internet draft.

A new page RRG-2009/constraints/ has a draft list of constraints on any scalable routing solution which result from our reliance on widespread voluntary adoption.  Please comment on this in the RRG list.

Added a page namespace/ as part of trying to determine the meaning of the noun "namespace".  This is part of a debate on the LISP list about whether or not statements about LISP involving separate namespaces for EIDs and RLOCs are accurate or not.  This is probably more than anyone ever wanted to know about the meaning of the term, but since the debate has involved the suggestion that "namespace" may have "a lot of other definitions floating around" I tried to find them - without success.

This paper:

the authors argue that "core-edge separation" approaches  is a better way of achieving scalable routing and addressing than  "core-edge elimination" schemes.  Core-edge separation schemes are "Strategy A" in Bill Herrin's taxonomy (below) and in the 3.3 taxonomy of the draft RRG recommendations.  Core-edge separation proposals include LISP, APT, Ivip, TRRP and Six/One Router.

Added a page rrgarch/ which attempts to match actual scalable routing proposals to the strategies in Bill Herrin's Summary of Routing Architectures: http://bill.herrin.us/network/rrgarchitectures.html . 

Forwarding with modified headers: I have devised two systems for getting packets from ITRs to ETRs without encapsulation or address translation.  Both systems require a modest upgrade to most or all core (DFZ) routers and for some or many internal routers - but would make for a much simpler, more efficient system, with no PMTUD problems and simpler ITRs and ETRs. 

Comparing LISP-NERD/ALT, APT, Ivip and TRRP (Does not cover Ivip's  Modified Header Forwarding arrangements.)

• comp/ 

See also the rrgarch/ page which attempts to match actual proposals to Bill Herrin's summary of strategies.

pmtud-frag/