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

From: "Christian Huitema" <[email-masked]>
Date: Wed, 21 May 2003 09:43:06 -0700

> 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.

I personally like conservative approaches. Brian, you asked in another
message whether multi-addressing is desirable. I don't think that the
working group should try to answer that "desirability" question. If we
want to make progress, we should rather charter two groups, and then let
the market choose. I would much rather see one group working on the
multi-addressing solution and another working on the split
locator-identifier solution, than trying to coerce everybody in a single
group.

As for multi-addressing itself, naros addresses one of the issues, i.e.
the choice of addresses by multi-addressing aware hosts. It is
definitely a possible component of the solution, but we should make sure
that we have a comprehensive charter. For example, in our own
multi-addressing paper, we tried to look at another issue, the behavior
of hosts that are not multi-addressing aware in a multi-addressed
network. Our requirement was that simple hosts should be able to
configure only a fraction of the possible addresses, and still be able
to function. So I guess one of the short term exercises should be to
draft a comprehensive charter for a multi-addressing working group. If
we could adopt that in Vienna, we would have achieved something.

-- Christian Huitema

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 22 May 2003 13:01:00 +0200

> locator-identifier solution, than trying to coerce everybody in a 

I agree with you that we should explore both solutions, but I don't 
think having two groups and eventually two standards will benefit 
anyone. Especially from a operational perspective where we would end up 
having to maintain both solutions.

I would rather suggest to form two design teams then.

> So I guess one of the short term exercises should be to

See above.

- kurtis -