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

[Brian E Carpenter <brian@hursley.ibm.com>]

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.

   Brian

Tony Li wrote:
> 
> |    > |    I don't think we can make informed decisions about the
> |    > |    architectural
> |    > |    approach unless we know how well each approach is going to
> |    > |    work out. That's why I keep going into detail.
> |
> |    > This is a common trap.
> |
> |    So then there must be a reason why it's hard to avoid it.  :-)
> 
> Good engineers are detail oriented.  Even when they shouldn't be.
> 
> |    Didn't we kinda sorta agree that loc/id is our collective favorite
> |    architecture and that the rest is either flawed, should be
> |    worked on
> |    elsewhere or no interest in working on it as a group?
> 
> I think that you and I agreed that.  However, if we are to truly build
> WG consensus on this issue, it's only fair that we allow supporters
> of alternatives to speak their piece.  I'm hoping that if there are
> any such folks, they will speak up, so that we are not accused later
> of shouting them down.
> 
> 
> |    Even though we get a bit sidetracked from time to time, I
> |    think we're
> |    having a very useful discussion on the identifier
> |    semantics and mapping
> |    mechanisms right now.
> 
> I think that the cart belongs behind the horse.  Until we get rough
> consensus on the architecture and make a decision, all other energies
> are a distraction from that milestone.
> 
> Tony

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland