Subject: RE: Start running

From: "Tony Li" <[email-masked]>
Date: Sat, 22 Mar 2003 23:22:04 -0800

Kurt,

|    Although I generally tend to agree with your view, I do 
|    think that we 
|    need let everyone present their opinions and evaluate 
|    them.

I fully endorse this.  But the implication of drafting full blown
proposals for each alternative is not one where you, as a manager,
set yourself up for success.  You instantly make it competitive and
not collaborative.

|    You and me 
|    have a certain view of where to go, maybe that is where we 
|    will end up 
|    eventually (of-course I hope so), but in order to start 
|    working on one 
|    single solution we need to have a consensus saying that is 
|    where we 
|    want to go. And we wont get there unless we have looked at the 
|    alternatives thoroughly.

Then we should apply good engineering practices (see problem
statement WG) and bound the problem, partition the solution space
and discuss the high level approaches.  Only after we have consensus
should we be pushing down into more details.

|    I have no problem with loading the chairs (I guess Sean 
|    will give me a 
|    hard time for this...:) ) if that brings us forward, and I 
|    think you 
|    are right, but I think we need to do some other steps first.

Ok, what and when?

Tony

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 23 Mar 2003 15:14:41 -0500

> set yourself up for success.  You instantly make it competitive and

	I'll try to paraphrase tli's view.

	Full and open discussion is necessary and helpful.  However, having
such discussion does not imply that the WG Chairs should create 
something
resembling a "horse race" to create competing proposals that will then
"fight it out".

	An alternative approach, one (IMHO) much more likely to be successful
in creating a co-operative WG environment, is to have an open discussion
that is thoughtfully structured, top down.  For example, the initial 
phase
of the discussion probably should be about the high-level technical 
issues
being addressed and possible architectural approaches to those issues.  
Once
rough consensus (smooth consensus not being a customary IETF 
requirement)
is achieved on the high-level issues and on the architectural approach,
the discussion could then move on to a next phase with a few high-level
engineering details being sorted out.  Once those are sorted out, an
additional level of detail could be addressed.  Only at the end would 
the
discussion delve into the nitty gritty implementation details.  This 
way,
the chairs would create a path forward that encourages competition 
rather
than cooperation.  And any good idea could be considered by the whole
group.

	By contrast, asking folks to create full-fledged proposals right
now does the opposite -- encouraging competition and confrontation,
rather than cooperation.

	Please consider taking the cooperative path forward.

Ran
[email-masked]

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 24 Mar 2003 10:13:10 +0100

> set yourself up for success.  You instantly make it competitive and

Ok, I think I have misunderstood you, or the other way around. I am not 
suggesting that we draft full blown solutions for each alternative. I 
think we need to have them all up for review and that we need to have 
enough meat on the bones to be able to make a judgment. Exactly what 
those are is still to be decided but should somehow me in the 
milestones IMO.

> should we be pushing down into more details.

Agree!

> |    are right, but I think we need to do some other steps first.

My personal view is (not discussed with my co-chair or the ADs in any 
greater length yet) that we need to a) Get the 'requirements' document 
shipped, B) We need to determine what solutions categories we want to 
look at c) We need to determine to what level of detail we want these 
solutions worked out d) We need to get the results of b) and c) into 
the WG charter and update the dates of the milestones e) we need to 
agree on what solution is to be worked out in more detailed

In terms of time-line this very much depends on how fast we can do b) 
and c). One scenario is that we work on b) and c) in parallel to c) and 
then discuss all of these in Vienna. That will be a very long WG 
session though...

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 24 Mar 2003 10:20:21 +0100

> resembling a "horse race" to create competing proposals that will then

That was not my intention or what I meant. See other mail to Tony.

> engineering details being sorted out.  Once those are sorted out, an

This sounds like what I proposed in the mail to Tony?

> 	Please consider taking the cooperative path forward.

I think you are describing what I said in the mail to Tony.

The problem as I see it at the moment is that there currently is no 
solution that is on the table and there is no "magic dust" (expression 
stolen). We need to start with realizing that we are at scratch (I know 
some people disagree). However, I also think that there currently are 
to many views on what the architecture should be based on. In order to 
better understand this, I think we need to look at the various 
architectural proposals made. This needs to be made as a working group, 
and then from there we need to work together on one solution.

Best regards,

- kurtis -

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 24 Mar 2003 08:26:13 -0500

On Monday, Mar 24, 2003, at 04:20 America/Montreal, Kurt Erik Lindqvist 
wrote:
> ...
> ...

It was certainly not apparent that your note to tli contained anything
like the proposal I outlined above.  Thanks for the clarification.

> The problem as I see it at the moment is that there currently is
> no solution that is on the table and there is no "magic dust"
> (expression stolen). We need to start with realizing that we are
> at scratch (I know some people disagree). However, I also think
> that there currently are to many views on what the architecture
> should be based on. In order to better understand this, I think
> we need to look at the various architectural proposals made. This
> needs to be made as a working group, and then from there we need
> to work together on one solution.

s/architectural proposals/architectural approaches/

Again, "proposals" sounds like one is trying to foster competition,
rather than cooperation.

And while opinions will vary about what constitutes "architecture",
maybe we all agree that architecture is extremely high-level,
hence devoid of most/all implementation details.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 24 Mar 2003 08:28:41 -0500

wrote:
>  However, I also think that there currently are to many views on what 
> the architecture should be based on.

The only architectural approach that I've seen on this list in recent
months is the notion of deprecating the concept of an "address",
in favour of using "locator" and "identifier" for the separate purposes
of routing and identity.  Maybe I've overlooked something ?

If there is another architectural approach in the wings, maybe someone
would be kind enough to summarise that alternate approach to the list ?

Ran
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Mar 2003 15:16:58 +0100

Kurt Erik Lindqvist wrote:
...
> In order to 

Can't disagree with that as a strategy. However, the 8+8 experience
was that you have to go a long way into the details to find out if
a solution is really useable. So it will be hard to avoid a detailed
analysis of each possible proposal.

   Brian

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 24 Mar 2003 17:03:03 +0100

> like the proposal I outlined above.  Thanks for the clarification.

Well, I think we are close anyway.

> hence devoid of most/all implementation details.

I think that this is what I would like to work out. A common 
understanding of what exactly want to put on the table to start with. 
What to call it, and how much details.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 24 Mar 2003 22:09:27 +0100

> of routing and identity.  Maybe I've overlooked something ?

Well, there is also Christians multiple address solution and on other 
lists there have been suggestions on using mobility based solutions.

> would be kind enough to summarise that alternate approach to the list ?

Well, I want to give people a few days to present their solutions 
(there are also a few personal drafts submitted to the IETF) or 'ask' 
to have them reviewed. Then we need to start to move on.

But in principal the division of solution space could be

- multiaddress
- Mobility based
- Location/Identifier separation
- Based on today (basically improved routing, but I haven't seen any 
real proposals on this).

- kurtis -

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 24 Mar 2003 16:19:50 -0500

On Monday, Mar 24, 2003, at 16:09 America/Montreal, Kurt Erik Lindqvist 
> But in principal the division of solution space could be

Does "Mobility-based" mean MIPv6 or something very similar ?

I would say that MIPv6 is an instance of Locator/Identifier
separation.  I'd guess there are lots of potential instances
of any given approach.  I was trying to take a much higher
altitude perspective on the potential approaches that are
fundamentally different from each other, then work top down.

> - Based on today (basically improved routing, but I haven't seen any 

I'm not sure what "based on today" means.  So if someone
does have a proposal for this, a high-level outline would
be pleasant.

Ran

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 25 Mar 2003 06:29:41 +0859 ()

Kurt, Tony, Ran;

> suggesting that we draft full blown solutions for each alternative.

Can you say "running code"?

							Masataka Ohta

---

From: marcelo bagnulo <[email-masked]>
Date: 25 Mar 2003 10:37:09 +0100

Hi Ran,

On Mon, 2003-03-24 at 22:19, RJ Atkinson wrote:
> separation.

I am not so sure about that. I would say that in MIP identifier and
locators are not separated. I mean, a given address can work both as a
locator and as an identifier, depending on the situation. Perhaps, I
would say that the identifier role and the locator role are separated.
Please, note that this is not related to the fact that locator space and
address space are the same (IP addresses) but that sometimes a given
address is used as a locator and other times as an identifier.
This is true also when considering transport layer solution such as the
modifications to TCP to support multiple addresses per connection.
This is different from the LIN6 case, where there is a specific type of
addresses reserved to serve as identifiers, in which case identifiers
and locators are clearly separated.

Thanks, marcelo

>   I'd guess there are lots of potential instances
-- 
marcelo bagnulo <[email-masked]>
uc3m

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 25 Mar 2003 08:14:40 -0500

On Tuesday, Mar 25, 2003, at 04:37 America/Montreal, marcelo bagnulo 
> would say that the identifier role and the locator role are separated.

Marcelo,

	As the Subject: line of the thread indicates, my comment
was from a high-level architectural perspective.  Architecturally,
MIPv6 separates the locators from the identifiers.

	Sure the implementation details might vary, but I'm
not interested (right now) in any implementation details.
I'm only trying to sort out the *architectural* or
highest-level differences between different approaches,
for now.

	If/after there is convergence on an architecture, then
would be a better time (IMHO), to sort through implementation
details.

Ran

---

From: marcelo bagnulo <[email-masked]>
Date: 25 Mar 2003 16:07:52 +0100

Hi Ran,

I am wondering if these two approaches are the same or not:

- The first case is where there is clear separation between locators and
identifiers. In this case, a binding between an identifier and one more 
locators is needed. 
- The other case is where multiple addresses are used for reaching the
other end. I am not sure that you need an identifier, all you need to
know is that there is a set of possible locators for reaching the other
end of this communication. (Perhaps the identifier is the set of
locators?)

Do you think that there is a difference between this two approaches?

Thanks, marcelo

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 25 Mar 2003 11:13:48 -0500

On Tuesday, Mar 25, 2003, at 10:07 America/Montreal, marcelo bagnulo 
wrote:
> - The first case is where there is clear separation between locators 
> and identifiers. In this case, a binding between an identifier
> and one more locators is needed.

A binding is *always* needed between any identifier and its set of
locators, even when the identifier happens to be the permanent
home address (using MIPv6 as an example) and the other addresses
are the locators.  The *nature* of that binding changes depending
on implementation details, but the need for some binding does
not change.

> know is that there is a set of possible locators for reaching the 
> other end of this communication. (Perhaps the identifier is the
> set of locators?)

If one considers MIPv6, there is only one IPv6 address that is
used for the TCP session state.  The address used in that way
is functionally an identifier.  The other addresses (i.e.
those not in the TCP session state) are functionally locators.

> Do you think that there is a difference between this two approaches?

At a high-level, no.  In gory implementation details,
of course yes.

As noted before, my goal (and I suspect tli's goal) pro tempore
is to discuss the high-level aspects only.  If/when/after some
consensus emerges at that level, it would then make sense
to dig one level deeper.  IMHO, it would not make sense
to dig deeply prematurely -- for fear that we'd be unable
to see the forest because of focus on individual trees.

Cheers,

Ran