[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]]
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 ;)
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
> 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.
> 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