Scalable Routing Proposals which match Bill Herrin's "Summary of Routing Architectures discussed in the RRG"

Established 2009-01-03 Robin Whittle, attempting to follow the RRG discussions, starting here: http://www.irtf.org/pipermail/rrg/2008-December/000592.html.
Last update (to version 02) 2009-02-24 - changes noted in Red..  

Important note 2009-03-01

Much of Bill's page has now been copied into the draft RRG report: http://tools.ietf.org/html/draft-irtf-rrg-recommendation .  Please see the latest version of this and discussions on the list, since that is the version which probably matters most, rather than Bill's page.  

I have made a page:  ../RRG-2009/rec/ which lists what I think is missing from the current draft of the RRG recommendations.

Version 02

The first version of this page was 00.  To see an older version xx, use this directory name with index-xx.html added.  Please don't link to these.

Please see my mailing list messages (Re: [rrg] Proposals which match rrgarchitectures.html pls check thepage) for the update history to version 01.


Context

Bill's page http://bill.herrin.us/network/rrgarchitectures.html

IRTF Routing Research Group wiki, including links to most proposals:  http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup
RRG mailing list after 2008-08-13:  http://www.irtf.org/pipermail/rrg/
RRG mailing list before 2008-08-13: http://psg.com/lists/rrg/

My attempt at a description of the root cause of the routing scaling problem which is not as focused (IMHO) on solving the problem in hosts as Bill's description: http://www.irtf.org/pipermail/rrg/2008-December/000525.html

Comparison of LISP, APT, Ivip and TRRP (April 2008, without considering Ivip using forwarding instead of encapsulation): ../comp/

Links to recent messages discussing either how certain proposals do or don't match Bill's Summary, or potential additions to the Summary:

Ivip:
http://www.irtf.org/pipermail/rrg/2008-December/000526.html (RW)
http://www.irtf.org/pipermail/rrg/2008-December/000543.html (BH)
http://www.irtf.org/pipermail/rrg/2008-December/000591.html (RW)    
http://www.irtf.org/pipermail/rrg/2008-December/000593.html (BH)

APT:

http://www.irtf.org/pipermail/rrg/2008-December/000606.html (Dan Jen)
http://www.irtf.org/pipermail/rrg/2008-December/000607.html (BH)
http://www.irtf.org/pipermail/rrg/2008-December/000610.html (Dan Jen)

Potential Strategy H:

http://www.irtf.org/pipermail/rrg/2009-January/000647.html (Hannu Flinck)
http://www.irtf.org/pipermail/rrg/2009-January/000649.html (BH)



Strategy A

These are core-edge separation schemes, with the new functionality being implemented in the network (in or near DFZ, ISP and end-user CE routers, but also for internal routers for Ivip forwarding approaches).  Will work with existing hosts (except that Ivip forwarding and PMTUD management won't accept fragmentable packets longer than a certain size.)
A paper arguing for this class of solutions (core-edge separation) and against the "elimination" class (Strategy B) is:

Towards a Future Internet Architecture: Arguments for Separating Edges from Transit Core
Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang
http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf

*   match.

*~ closest match, but not a full description.

A1

I am uncertain about these. See the discussion 2008-December/000591 (RW) and 2008-December/000593 (BH).  For now, I am matching them all with A1c, since it is my impression this best reflects the current BGP arrangements, and since I understand that none of these proposals require a change in ISP's BGP arrangements.

      LISP-  LISP-  APT    Ivip   TRRP   Six/One
      NERD   ALT                         Router

A1a
A1b
A1c   *      *      *      *      *      *

A2

It is not clear which, if any, of these variants best matches APT.  Six/One Router has no specific mapping system.  

      LISP-  LISP-  APT    Ivip   TRRP   Six/One
      NERD   ALT                         Router

A2a   *                                      
A2b                
*~?    *~
A2c          *      
*~?           *       

A3

      LISP-  LISP-  APT    Ivip   TRRP   Six/One
      NERD   ALT                         Router

A3a   *      *      *             *      *     
A3b                        *  


A4

I think none of the proposals match A4a or A4b.  

This was the text from version 01:

LISP, APT and TRRP match the encapsulation description of A4c, but AFAIK, they do not have specific arrangements for dealing with the resulting Path MTU Discovery problems.  A4c specifies a particular method of doing this, which I argue is impractical: [RAM] ITR complexity & security (ICMP) in LISP-NERD/CONS & eFIT-APT 2007-07-28: http://www.ietf.org/mail-archive/web/ram/current/msg01766.html .  I don't recall anyone arguing it is practical.

Here is some new text:
There was a discussion of LISP's PMTUD approach on the list starting in late January 2009 in the thread "LISP PMTU - 2 methods in draft-farinacci-lisp-11".  There I agreed that LISP does have a PMTUD approach, but that it is not as fully developed as mine: ../pmtud-frag/ .  That approach came from the Open-LISP project.  I think that if it was fully developed to be secure and to reduce the amount of state to be held by the ITR (for instance by only holding state for packets which might cause MTU problems) then I think this approach would come to resemble the one I propose.

      LISP-  LISP-  APT    Ivip   TRRP   Six/One
      NERD   ALT                         Router

A4a                                          
A4b  
A4c  
*?     *?     *?            *?          
A4d                       *(encaps)           
A4e                                     *   
A4f                       *(PLF v6)             
A4g                       *(EAF v4)            


A5

I think none of the proposals match A5b or A5c.

      LISP-  LISP-  APT    Ivip   TRRP   Six/One
      NERD   ALT                         Router

A5a   *      *      *      *      *      *   
A5b                                          
A
5c                                              




Strategy B

This is the elimination class of proposals.  Any such proposal requires new host functions, including changes to host stacks, APIs and applications.  Strategy B solutions do not not require changes to the interdomain routing system or to the rest of the network, except perhaps improvements to DNS.

No-one is suggesting such a solution for IPv4 - they are all modifications to IPv6.  This is due, in part, to the lack of IPv4 address space required for this technique, in which each multihomed end-user network has a block of space from each upstream ISP, of the same size as its network's address space.

ILNP is one such proposal, I think.  HIP may be another.  However neither of these is fully documented as a solution to the routing scaling problem.
(See #discuss-01 below - maybe neither of these really fit Bill's description.  For instance, do either have a mapping system?)

Can anyone confirm this or suggest other proposals?  Can anyone write about B1x and B2x with respect to actual proposals?

Marcelo Bagnulo Braun suggests ProxySHIM6 may be a Strategy B approach.  I know nothing about it.



Strategy C


Geographic aggregation.  Heiner Hummel has been proposing this for at least a year - but there is no substantial documentation of this or any other such proposal.



Strategy D


I don't know of anyone proposing FIB compression as a solution for the routing scaling problem.


Strategy E


There has been no serious discussion of a billing systems for DFZ routes on the RAM or RRG lists.  Has there every been a serious proposal along these lines?


Strategy F


Not a solution - do nothing. 


Strategy G


The original vision of IPv6: those end-user networks which wanted multihoming would get a PA prefix from each of their two or more ISPs, and use SHIM6.  


Loose Ends and Discussion

(#discuss-01) Please see Marcelo Bagnulo Braun's message: http://www.irtf.org/pipermail/rrg/2009-January/000668.html .

In version 00 I had SHIM6 in Strategy B, but Marcelo is correct in pointing out it doesn't match my description of requiring API or application changes.  Nor does it match Bill's description, at least in this respect: "GUID to LOC maps are pushed from the host towards a distributed registry as they change. Hosts request and temporarily cache individual mappings from the registry as needed."

Does ILNP really match Bill's Strategy B description?  Does it have such a mapping system?

What about HIP?  Does it fully match Bill's description?

I deleted mention of SHIM6 from Strategy B and retained mention of it in Strategy G.

Please see my list message http://www.irtf.org/pipermail/rrg/2009-January/000670.html for discussion of whether ProxyShim6 is a scalable routing solution, and whether it matches any existing Strategy.

.