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

[marcelo bagnulo <marcelo@it.uc3m.es>]

Hi Brian,

I would say that these three are not _options_ but three approaches that
we should follow since the three of them are needed (i do not know if
this is what you meant)

Immediate solutions for big sites (option 1) and for small sites (option
2).

Long term solution Option 3 we have to discuss which one of them (or
others)

I think we have to do the three of them and i think this is a good
roadmap.

Thanks for the writing,
regards, marcelo 

On Wed, 2003-05-21 at 12:02, 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
-- 
marcelo bagnulo <marcelo@it.uc3m.es>
uc3m