"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 [EMAIL PROTECTED] 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
