Subject: [rrg] Ivip architecture ID rewritten, 2 others updated

From: Robin Whittle <[email-masked]>
Date: Thu, 14 Jan 2010 01:20:25 +1100

I have replaced the original Ivip-arch ID with a freshly
written version 03.  This is completely up-to-date and should
be easy for RRG people to read without much head-scratching:

  http://tools.ietf.org/html/draft-whittle-ivip-arch-03

This is 2 or 3 hours reading - 25k words, 61 pages of material,
not counting TOC, references etc.

Please don't complain about it being long.  We are deciding how
to upgrade the world's biggest and most significant IT system.
This is 40% shorter than the previous version.

This ID gives a good account of all aspects of Ivip, with goals,
non-goals and the architectural choices which lead to Ivip.

This is for IPv4 and IPv6, with encapsulation and its PMTUD
problems, and with alternatives to encapsulation.  It also
covers mobility.

This is the sort of scope a scalable routing proposal should
have.  If you paid good money for one which doesn't go this far,
I reckon you should be entitled to a refund!

The TOC follows my signature.

I have also updated the other two IDs - on the fast-push mapping
distribution system and on the Modified Header Forwarding
arrangement for replacing encapsulation in IPv4 (which requires a
modest upgrade to DFZ router FIBs).

  http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-02
  http://tools.ietf.org/id/draft-whittle-ivip-etr-addr-forw-00

 - Robin

 1. Introduction

 2. Goals

           IPv4 and IPv6

           Portability, multihoming and TE for billions of end-user
           networks

           Modular separation of the control of mapping from the
           core-edge separation architecture itself

           Simple ITRs and ETRs with little or no communication
           between them

           Maximise the flexibility with which ITRs and ETRs can be
           located

           Mobility

           Elimination of encapsulation and PMTUD problems

           No requirement for new host functionality

           Full benefits to all adopters

           Business incentives to deploy new infrastructure

           Maintenance of existing levels of security and robustness

 3. Non-goals

           Complete core-edge separation is not required

           Mapping changes need not be free of financial cost

           No attempt to cope with partially reachable ETRs

           No attempt to avoid all the mapping data being stored at
           any one location

           It may not be possible to completely eliminate unfair
           burdens

           No attempt to mix IPv4 and IPv6

           Not Locator - Identifier Separation

4.  Architectural Choices

           Core-edge separation rather than elimination

              Core-Edge Elimination (CEE) architectures
              Core-Edge Seperation (CES) architectures

           Local query servers

           Real-time mapping distribution

           SPI address management

           IP in IP encapsulation

           MHF initially or in the long term to avoid encapsulation
           and PMTUD problems

           Outer header address is that of the sending host

           IPTM (ITR Probes Tunnel MTU) PMTUD management

5.  Architectural Elements

          ITRs

              Types of ITR and their addresses
              DITRs - Default ITRs in the DFZ
              Modified Header Forwarding - MHF-only ITRs
              Encapsulation and PMTUD management
              Mapping lookup and caching
              ITFH - ITR Function in Host
              ITRs auto-discovering local query servers
              ITRs regulating their advertisements

          ETRs

              In servers or dedicated routers
              ETRs in ISP networks
              ETRs at the end-user network site
              MHF ETR functionality - EAF and PLF
              ETR functionality for encapsulation

          QSDs - full database query servers

              Placement in ISP and end-user networks
              QSD initialization and reception of mapping updates
              Responding to queries
              Sending mapping updates to ITRs and QSCs

          QSCs - caching query servers

          FMS - Fast-Push Mapping Distribution System

          MHF - Modified Header Forwarding

              EAF - ETR Address Forwarding for IPv4
              PLF - Prefix Label Forwarding, for IPv6

          TTR Mobility