Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]]

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 21 May 2003, Brian E Carpenter wrote:
> Tony is correct, we need to take the big decisions first. So, I think we
> have these options to consider:
> 
> 1. For really big enterprises, leave the RIRs to set a policy that
> allows such enterprises to get a /32 and negotiate appropriately
> with ISPs. No work for the IETF.
> 
> 2. Design a multi-address based solution, where an enterprise would 
> have multiple PA prefixes and some technology would be added to support 
> address selection. draft-de-launois-multi6-naros-00.txt
> might be the starting point.
> 
> --> this is a conservative approach. It doesn't change anything in
>     the addressing or routing architecture. We could write a WG
>     charter for this quite easily.
> 
> 3. Design a two-level solution, in which a locator is used
> for routing and an identifier is used end2end (and possibly 
> for local routing). There are several sub-options:
> 
> 3.1 Map-and-encapsulate, i.e. tunnels driven by a distributed mapping.
>     In this case, both the locator and the identifier can be standard
>     addresses, the identifier perhaps being something like
>     draft-hinden-ipv6-global-local-addr-00.txt.
> 
> 3.2 Splitting the address into two fields, and swapping routing prefixes
>     en route (a.k.a. GSE)
> 
> 3.3 Swapping & restoring addresses en route. Again, both the identifier 
>     and locator can be standard addresses.
> 
> 3.4 Carrying the identifier, whatever it is, in an extension header.
> 
> All of these carry the need for locator mapping. Actually, the multi-address 
> method also needs equivalent mapping information, it's just a bit hidden. 
> So that seems to be our fundamental piece of magic. 800 numbers, anybody?
> 
> It seems to me we can plausibly pursue all three of the above approaches,
> with 1) being immediate, 2) being medium term and any of 3) being long term.
> 
> 4. Transport layer solution. My belief is that TCP is too entrenched for
> this to be a reasonable approach.

I think we need to realize that these four options solve different 
problems, and not all of them completely.

Based on a quick look, it seems to me that:

 - being able to switch ISP's without renumbering: 1), 3.2), maybe others
 - redundancy due to link failures etc.: 1), maube 2), maybe 3)
 - connection survivability (internal connections, external connections) 
1), 4), maybe some of 3)
 - more fine-grained (ie. not 50/50) inbound traffic engineering: maybe 
1), 2)
 - the maximum frequency of ISP (=prefix) changes: 1), maybe some of 3)


I can summarize this at least to:
 - even if we modify all the transport layers to be address-agile, it's 
not enough.
 - if we need connection survability (some might not), it needs to be 
coupled with some other solution which provides capabilities for it (ie. 
multiple addresses), or inherently provides it (PI address, GSE?)

So, I must conclude we must be very, very careful in determining our 
options (and what exactly those options are good for).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings