[RRG] Ivip6 (previously FLOWv6), Ivip4 and Ivip

[Robin Whittle <rw@firstpr.com.au>]

"Ivip6" is the new name for my "FLOWv6" proposal I wrote to the list
a few days ago.

For now, I think it can be referred to as a

   "Core Routing Label Tunneling" (CRLT)

system to distinguish it from the two other approaches to "Core-Edge
Separation".

If anyone can think of a better term for this, I would be glad.

So this, by one name or another, needs to be a third branch under
the "Core-Edge Separation" branch of Jari's diagram:

  http://www.arkko.com/ietf/rrg/designspace_dataplane.jpg


                     Core-Edge Separation
                     |
     ------------------------------------
     |                  |               |
     |                  |               |
     Encapsulate        Translation     Core Routing Label Tunneling
     (map-encap)                        (CRLT)

     LISP               Six/One Router  Ivip6
     APT
     Ivip4
     TRRP


In the next few days I plan to write an updated version of the
proposal to:

   http://www.firstpr.com.au/ip/ivip/ivip6/

changing a few names (ITR instead of IFR etc.) and providing some
further details.

It will take me a while to revise my Internet drafts and web pages,
but I plan to use these terms in the future:

  Ivip   will mean the overall architecture of both proposals,
         one for the IPv4 Internet and the other for the
         IPv6 Internet.

         (They are separate, standalone, proposals, but share many
          common principles and functional units.)

  Ivip4  will be the IPv4 map-encap approach.


  Ivip6  will be the IPv6 "Core Routing Label Tunneling" (CRLT)
         system.


While the Ivip map-encap technique could also be applied to IPv6, I
believe that there are so many benefits of using the current Flow
Label bits as a Routing Label in the core, that I will suggest Ivip6
approach alone for IPv6, not the map-encap approach.

The two primary things which need to happen for Ivip6 to be feasible
are:

  A - Rename the 20 bit "Flow Label" in the IPv6 header to "Routing
      Header" and develop new semantics for it - to support Ivip6
      in the core and potentially other uses outside the core.

      Recent messages from Brian Carpenter and Tony Li indicate the
      bits are probably not currently used for any substantial
      purpose:

        http://psg.com/lists/rrg/2008/msg02041.html
        http://psg.com/lists/rrg/2008/msg02049.html

  B - Ensure a sufficiently high proportion of IPv6 BGP routers have
      modest upgrades to their FIB and RIB functionality, by the
      time Ivip6 is deployed.  There is no change to the BGP
      protocol or implementation.

      The FIB's array of FEC values, which I called FINDEX[] in the
      original proposal, doesn't need to be 2^20 bits long.  We
      won't need that number for a long time, if ever.  I will write
      about this in a separate message replying to Brian Carpenter
      about this: Ivip6: number of "Flow Label" bits required


The benefits of the Ivip6 approach over the Encapsulate (map-encap)
techniques seem to include:

  1 - No header overhead.  Packets remain the same length.

  2 - No PMTUD problems whatsoever - a Packet Too Big message will
      be sent to the sending host, with the original packet details,
      from any router in the full path, including the CRLT portion
      of the path.  (I assume that the sending host won't care if
      the "flow label" bits in the returned packet fragment are
      different - maybe this will require a minor tweak to host
      stacks.)

  3 - Significant reduction in computational effort for each such
      packet passing through a core router, compared to it fighting
      its way through up to 48 bits of destination address to
      determine the packet's Forwarding Equivalence Class.

  4 - Traceroute will work fine through the full path, including the
      CRLT portion of the path.

These are all major benefits.  The first three are major factors in
the complexity, communications overhead and computational demands of
handling packets which are sent through the core to hosts in the new
scalable form of end-user networks.

The benefits over Translation (Six/One Router):  seem to include:

   1 - No address rewriting, so:

       a - Less complexity and computational effort in the
           ITR and ETR functions ("translation routers" in
           Six/One Router).

       b - No problems with the header changing in ways which
           upset IPsec or other cryptographic protocols.

   2 - No need for using a prefixe of provider space to match each
       prefix of end-user network space.

   3 - Ivip6 includes OITRDs (like LISP PTRs) to collect
       packets from non-upgraded networks, so there is full
       support, including for multihoming, for hosts in networks
       without ITRs.  This is vital for making the system
       attractive even when few other networks have adopted it.


  - 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