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

[Tim Chown <tjc@ecs.soton.ac.uk>]

This looks good.   For #2, Christian also presented a 4-6 stage plan that
would enable such a solution.  I haven't read launois-multi6-naros-00 yet,
maybe it is similar to Christian's proposal.

If we have concensus on this, we could build and agenda around it.

But I am very aware there are other proposals, which should be allowed a
fair shout (or which may go their own commercial way anyway ;)

Tim

On Wed, May 21, 2003 at 12:02:26PM +0200, 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.
> 
>    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