Subject: Re: Mutli6 meeting in Vienna

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 13 May 2003 10:06:02 +0200

On fredag, maj 9, 2003, at 12:48 Europe/Stockholm, Coene Lode wrote:

>>
>> I am still also open to input on the agenda and the structure of the
>> meeting. From the past weeks discussions here I would assume
>> that "GSE"
>> will be a large topic, but we would need something to discuss around.
>> We also have Pekkas draft and we have the option to have someone go
>> through the options brought to the IETF so far (I was going
>> through the
>> ID archives but I could't find much more than my drafts, Iljitsch,
>> Tonys and Michels expired drafts. Then we also have HIP. Have
>> I missed
>> something?). Opinions?
>
> There are folks out that can do multihoming already(via SCTP using 
> multiple
> addresses)
> I can present something on that(if you don't mind).

Again, there are a number of proposals and I am sure that everyone 
would like to present, but I don't think we can fit them all in. My 
reason for asking was to make sure that we have an overview solution 
that covers them all.

- kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 13 May 2003 23:50:33 +0859 ()

Kurt;

> >> will be a large topic,

GSE is not a proper name of any topic.

> >> but we would need something to discuss around.

You miss LIN6.

> reason for asking was to make sure that we have an overview solution 

"The Architecture of End to End Multihoming"
<draft-ohta-e2e-multihoming-*.txt> has been giving an overview
on so-called host based solutions in a way not specific to LIN6
before the WG was created.

Thus, I'd like to have a chance of presentation.

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 14 May 2003 09:34:33 +0200

> GSE is not a proper name of any topic.

...which is why I put it in quotes.

>>>> Tonys and Michels expired drafts. Then we also have HIP. Have

What is the draft name? I can't seem to find this.

> Thus, I'd like to have a chance of presentation.

As I said yesterday, we will not have time at this meeting for all the 
proposals to present. Instead we will try and have an overview of 
solution classes. Most work seems to be done with loc/id separation and 
Christians host-based solutions. For the time being this is where I 
think we should spend time at the meeting. We might want to spend more 
time on other solutions at the next meeting.

Unfortunately we have some catching up to do and having all proposals 
presented would take up very much time, without us moving on. Even then 
what to do in order to forward would not be clear. Therefor discussing 
the solution classes seems as a good compromise to me. Then looking at 
the (from my POV) two mostly supported proposals and try to iron them 
out a bit seems feasible. Me and Sean are discussing exactly how to do 
this.

- kurtis -

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 14 May 2003 17:04:33 +0900

Hi,

> What is the draft name? I can't seem to find this.

On LIN6 documentation, including the draft available on
http://www.lin6.net/index.html

The LIN6 draft was presented in 2001 in Mobile IP WG and IPv6 WG, but
probably too late at the end of the meeting to receive the interest it
deserves. There are many people still working on it, having actual
implementations, etc. 

By the way, some NEMO folks are working on a multihoming taxonomy draft
that you would find interest in, since site-multihoming is one feature
that would be particularly useful for NEMO.

Actually, this is the reason why Friday I posted an email to this list,
enquiring about your current definition of site-multihoming, but no
reply. The answer to the question is not clear while reading the charter
AND the draft: it's not consitent. 

I need this question because I would like to know if, say, a mobile
network deployed in a vehicle can be considered a "site".

Thierry

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 14 May 2003 16:53:07 +0859 ()

Kurt;

> What is the draft name? I can't seem to find this.

I will prepare it, if there is a chance for presentation.

> proposals to present.

Are you saying that you have tried to request 3 slots and denied by
IESG?

Or, are you just saying you are not so sure?

> Instead we will try and have an overview of 
> solution classes.

That's why I'm asking for presentation of the overview on end to
end multihoming.

> Most work seems to be done with loc/id separation and 

What do you want to discuss on solution classes? Isn't it already
obvious that the only solution class is host-based one with loc/id
separation?

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 14 May 2003 10:16:33 +0200

> I will prepare it, if there is a chance for presentation.

I got the draft mail to me in private. Reading to it quickly I noticed 
that parts of this solution is actually pending patent?

> Or, are you just saying you are not so sure?

I am saying that I do not think it would be useful for us to request 
three slots. I don't think that will move us forward.

> That's why I'm asking for presentation of the overview on end to

I think we are looking at one single presentation listing the solution 
classes. Pekka have volunteered to make such a presentation and we will 
most likely take him up on this offer.

> obvious that the only solution class is host-based one with loc/id

I said I wanted an overview. If that means discussion or not remains to 
be seen. I would personally be happier if not.

I don't think that there is a clear view on host based solutions vs 
loc/id and I am definitely not sure that host-based with loc/id is 
obvious. But that is why we are having this discussion.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 14 May 2003 10:22:55 +0200

> network deployed in a vehicle can be considered a "site".

I think the charter is pretty clear "A multihomed site is a site that 
has more than one connection to the
public internet with those connections through either the same or
different ISPs."

The draft says "A "multihomed" site is one with more than one transit 
provider. "Site-multihoming" is the practice of arranging a site to be 
multihomed.".

I don't see a conflict between these two and I would say that the 
answer to your question is yes?

- kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 14 May 2003 17:24:23 +0859 ()

Kurt;

> three slots. I don't think that will move us forward.

You mean you shall not have time.

I don't think it a good management of WG.

> most likely take him up on this offer.

Having presentation by Pekka, you will get view of Pekka, but nothing
more than that, which is not so productive.

> obvious. But that is why we are having this discussion.

That is not a productive way of discussion.

Discussion on solution classes, if any, should be more abstact
and should not be based on specific proposals.

Overview on specific proposals is a different topic.

							Masataka Ohta

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 14 May 2003 17:41:31 +0900

Hi Kurt,

Thanks for the answer. More below.

> I don't see a conflict between these two 

OK, my concern was about the Charter saying "either the same or
different ISPs" while the draft says "more than one ISP".  

This sounds conflicting to me and I don't know how many prefixes my
site-multihomed network is supposed to have.

> and I would say that the answer to your question is yes?

Well, that first depends on the first question (same ISPs or not) and
then I would like to know where my prefix(es) come from.

Is there any restriction on the length of the prefix for a network to be
considered site-multihomed ?

Thanks,
Thierry

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 14 May 2003 11:08:09 +0200

> I don't think it a good management of WG.

I am worried that we would spend large amount of time in our first 
meeting for a long time going through proposals, without a clear 
picture of where this would lead us. From what I can see there are very 
few proposals that have any broader support.

HOWEVER, Randy and Sean have an idea of a different way we can do the 
meeting and perhaps achieve what you want as well as try and get 
something useful out of it.

I will try and write this up during the day.

> more than that, which is not so productive.

Well, I was not going to ask him to present his views of the proposals. 
Rather a summary of the classes of solutions we see. Without any 
comments on the solutions as such. That is also what I understood that 
he was willing to do.

> Overview on specific proposals is a different topic.

That is why I wanted this split in to parts. One to give the overview 
(abstracts if you want) of the classes of solutions, one part on the 
proposals that appears to have the widest support.

But I will try and write up the alternative idea during the day.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 14 May 2003 11:10:42 +0200

> site-multihomed network is supposed to have.

Ok, I see your point. Personally I would think the charter is more 
correct for the normal use of the term "multihoming" but for the 
problem we are looking at, I would say that the draft is more accurate.

> considered site-multihomed ?

The answer to both of your questions depend on what suggested solution 
your are looking at.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 May 2003 11:22:44 +0200

On woensdag, mei 14, 2003, at 09:34 Europe/Amsterdam, Kurt Erik 

> As I said yesterday, we will not have time at this meeting for all the 

Note that the above isn't so much a proposal as discussion with some 
conclusions about what a solution should look like.

> Instead we will try and have an overview of solution classes. Most 
> work seems to be done with loc/id separation and Christians host-based 
> solutions. For the time being this is where I think we should spend 
> time at the meeting.

I've been trying to come up with a useful approach for this for a 
while. We really have to get this right because if this turns out to be 
a huge shouting match or nap time, it's the end of multi6.

How about this: if everyone says what proposals they feel are worth 
working on. Then we can discuss those proposals. It seems likely the 
proposals that many people want to work on have some promise. I think 
this is a good way to get around "this proposal sucks" "no it's great" 
type of discussions. The other advantage is that it limits the number 
of "active" proposals significantly. For instance, my geo stuff doesn't 
require work but simply adoption  :-)  so there is no need to go over 
it. Mobility and HIP have their home elsewhere, so those don't have to 
be discussed either, apart from maybe send an annotated copy of the 
requirements to those groups to make this stuff work well with 
multihoming.

So that leaves the whole locator/identifier thing. A few questions 
about that:

- on what layer do we want to do this?
- can we break applications?
- can we break transport protocols?
- can we break autoconfiguration?
- can we break IP?
- can we break IPsec?
- if we can't break something, what are the alternatives?
- where can we add state?
- can it be done without state?
- do we need a discovery protocol?
- do we need a negotiation protocol?

> presented would take up very much time, without us moving on.

Everyone should read the drafts.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 14 May 2003 12:08:54 +0200

>> work seems to be done with loc/id separation and Christians 
>> host-based solutions. For the time being this is where I think we 
>> should spend time at the meeting.
>
> while. We really have to get this right because if this turns out to 
> be a huge shouting match or nap time, it's the end of multi6.

I think that we will need some discussions (I don't like shouting). I 
to some extent think that is unavoidable with the number of proposals 
out there. However, after the discussions we also need to decide on the 
way forward.

> of "active" proposals significantly. For instance, my geo stuff 
> doesn't require work but simply adoption  :-)  so there is no need to 
> go over it.

Ok, stay tuned for suggested agenda to come.

>  Mobility and HIP have their home elsewhere, so those don't have to be 
> discussed either, apart from maybe send an annotated copy of the 

Agreed.

> So that leaves the whole locator/identifier thing. A few questions 

My views

> - on what layer do we want to do this?

IP

> - can we break applications?

if break=modify, we might be forced to.

> - can we break transport protocols?

see previous.

> - can we break autoconfiguration?

yes.

> - can we break IP?

yes

> - can we break IPsec?

isn't that transport?

> - where can we add state?

As little as possible.

> - can it be done without state?

Remains to be seen.

> - do we need a discovery protocol?

Discovery of?

> - do we need a negotiation protocol?

Negotiation of what?

> Everyone should read the drafts.

First they need to be submitted..:-)

- kurtis -

---

From: Pekka Savola <[email-masked]>
Date: Wed, 14 May 2003 13:54:10 +0300 (EEST)

> considered site-multihomed ?

"Site multihoming" to one provider (called site multiconnecting in the v4 
draft) is basically a no-brainer, AFAIK.  Is there something here which 
leads you to believe we need to work on this?

We could push multi-connecting as a solution/workaround for some use cases 
though.  IMO, that makes perfect sense to me, but at the same time, it 
cannot meet *all* the sites' needs, so we need something else too.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Wed, 14 May 2003 13:57:54 +0300 (EEST)

> few proposals that have any broader support.

I totally support this approach -- everyone presenting their own proposals
(mine included :-) -- does NOT seem like the good management at this time,
regardless of the time it would or would not take.
 
> comments on the solutions as such. That is also what I understood that 

Agree.  Even though I have my own preferences to the proposals, I don't 
think this would be the right place to push them.

(And if there is something, I'd circulate it among the folks whose
proposals are affected to be able to comment if they feel something is 
being misrepresented.)

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 14 May 2003 20:28:27 +0859 ()

Kurt;

> picture of where this would lead us.

It is a job of chairs to assign appropriate amount of time for
each presentation.

It is a job of chairs to reserve appropriate amount of time for
the wrap up discussion.

> From what I can see there are very 

That's why we need presentations and discussions.

We shouldn't expect Pekka can draw a clear picture to lead us.

> comments on the solutions as such. That is also what I understood that 

It's Pekka's view of classification.

> proposals that appears to have the widest support.

You are saying to select proposals that appears to have the widest
support based on the Pekka's view of classification.

That's not fair.

Worse, a good class can contain poor solutions that classes
and solutions are rather orthogonal.

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 14 May 2003 17:18:31 +0200

> It is a job of chairs to reserve appropriate amount of time for

There is also the job of the chairs to sense which proposals have 
backing and which do not. That is currently pretty clear to me. Also 
note that the sessions (at least to me) are not meant for presentations 
of the proposals, they are meant as possibility for clarification or 
discussions of a certain solutions viability. But see my mail on 
proposal for the agenda.

> That's why we need presentations and discussions.

Why? If there are few proposals with wide support, that to me is an 
achievement over many proposals with little support. We are trying to 
move towards a very distant consensus here.

> We shouldn't expect Pekka can draw a clear picture to lead us.

Well, at some point someone will have to. Be it me and Sean, the IESG 
or Pekka as presenting an overview.

> It's Pekka's view of classification.

I haven't seen much disagreement on that here though.

> support based on the Pekka's view of classification.

No. I am saying that there are few proposals here that are a) Being 
discussed b) Seems to have any support that is wider than the author. 
Some of the proposals would not even have the support of their authors 
if we where moving forward on a longer term solution (like mine and 
Iljitsch I guess).

> and solutions are rather orthogonal.

Again, I only see work being done on loc/id and some on host based 
solutions. There are good and bad suggestions and characteristics in 
both of those discussions. That are why we are having them.

But see suggestion for agenda.

- kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 15 May 2003 06:58:35 +0859 ()

Kurt;

> both of those discussions. That are why we are having them.

Personally for me, that's fine.

I'm tired of repeated discussion against geo and GSE.

But there are many loc/id proposals to be compared that your statement:

> solutions.

does not help the situation.

							Masataka Ohta

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 15 May 2003 11:47:25 +0900

Hi,

> draft) is basically a no-brainer, AFAIK.  

I'm happy to learn it's a no-brainer, that was not my perception, but I
need a little more thoughts on this. Is there any recommended document
we should read to understand the problem space (besides the multi6 i-d)
?

> Is there something here which leads you to believe we need to work on this?

No, I'm just trying to understand the problem space in the case I
connect an in-vehicle network to different ISPs, where the prefix should
come from, its length, etc, and also scalability concerns (there are 700
Millions vehicles in the world). So, I have a strong interest in the
word conducted in Multi6. We have to make sure your forthcoming
solutions will work for NEMO.

Thanks,
Thierry

---

From: Pekka Savola <[email-masked]>
Date: Thu, 15 May 2003 09:03:17 +0300 (EEST)

> we should read to understand the problem space (besides the multi6 i-d)

No.

Well, I've covered it very briefly in my thesis, available at:
http://staff.csc.fi/psavola/di.ps

The main thing is that if you're multiconnecting inside the ISP, you don't 
need more than one set of addresses, at least in the typical case.  In 
that case, the ISP can route them appropriately to you any way you agree 
about it.

But if you consider this from the "small customer" perspective, e.g. a 
laptop with both GPRS and WLAN interfaces *to the same ISP*, the problem 
space is probably not that much different from the two ISP case.

> solutions will work for NEMO.

Ok, thanks for info.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 15 May 2003 11:53:43 +0200

> I'm tired of repeated discussion against geo and GSE.

To be honest, I don't see you make any comments on either of these. I 
see you make comments that they won't work and that you have a solution 
ready that we should all adopt and be done with. Personally I would be 
interested in seeing you write up a technical basis for your reasons 
against these and then we could move from there.

- kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 15 May 2003 19:04:11 +0859 ()

Kurt;

> To be honest, I don't see you make any comments on either of these.

For GSE, read the draft.

> Personally I would be 

It has been there before the WG existed.

I see no point repeating it here for you.

Read the draft.

For geo, I saw several good reasoning against it by someone else
at the first several rounds that I see no point repeating it
by myself.

							Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Thu, 15 May 2003 13:23:54 +0300 (EEST)

> Read the draft.

Write the details.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 15 May 2003 19:30:25 +0859 ()

Pekka;

> Write the details.

On which part of the draft?

Read the draft and, if you want details, ask the questions.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 May 2003 13:54:45 +0200

Kurt Erik Lindqvist wrote:
...
> > - can we break autoconfiguration?

On all these, please see goals 3.2.2 and 3.2.3 of the goals (ex-requirements)
draft. If we don't meet those goals (carefully defined backwards
compatibility with existing, shipped router and host code) the solution
will be a non-starter. So certain things can be "broken" but only subject
to real-world compatibility constraints with shipping code.

   Brian

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 15 May 2003 16:13:03 +0200

>> To be honest, I don't see you make any comments on either of these.

Are your comments in the draft? I have read the draft of the proposal.

> I see no point repeating it here for you.

This is the LIN6 draft? If so I will as soon as I am back from RIPE.

> at the first several rounds that I see no point repeating it

Good. Then that is clear. The problem (and this goes for the entire 
working group though - perhaps even for many other WGs) is that if 
people just agree and don't post, it's very hard to follow where people 
think we should go. I talk to a number of people and I have started 
getting a large number of private emails, and therefor think I have a 
pretty good feeling of what people seems to think. But that is not 
really an issue here for this discussion.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 15 May 2003 16:23:25 +0200

On torsdag, maj 15, 2003, at 13:54 Europe/Stockholm, Brian E Carpenter 

Agreed.

- kurtis -

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 May 2003 18:35:03 +0200

> Read the draft and, if you want details, ask the questions.

drafts are supposed to be pretty complete.  if you want to be taken
seriously, get serious.

randy

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 16 May 2003 06:38:55 +0859 ()

Randy;

> drafts are supposed to be pretty complete. if you want to be taken

My draft is complete, as an architectural one.

Remember that the first version was taken seriously by you and
Harald.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 16 May 2003 06:45:14 +0859 ()

Kurt;

> that parts of this solution is actually pending patent?

As I say "I will prepare it", that is not my draft. LIN6 was
originally proposed by Prof. Teraoka and he seems to have
tried to get patent on something. After that, I use
some quite generic componet of LIN6 to make it a solution for
multihoming. I don't know whether the pending patent is useless
or strong enough to cover all the multihoming solutions. Ask
Prof. Teraoka.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 16 May 2003 06:54:02 +0859 ()

Kurt;

> Are your comments in the draft?

Yes.

	"The Architecture of End to End Multihoming"
	<draft-ohta-e2e-multihoming-*.txt>

has been there with several revisions each posted to the ML. You
can dig it, or I can mail you privately.

> I have read the draft of the proposal.

It is not a draft of a proposal.

> think we should go.

That could be a valid argument for the first and, maybe, second round
with little posting.

However, at all the round, many people just disagreed and posted
that it is not even so.

Anyway, at the third round and thereafter, it is a poor management
to allow same topic repeated again and again.

							Masataka Ohta

---

From: Sean Doran <[email-masked]>
Date: Thu, 15 May 2003 23:13:46 +0100

> Remember that the first version was taken seriously by you and

And me.  However, two things stand out:

(i) I made a number of comments and asked some questions
     on the list after having read through your draft; and

(ii) The draft is old and needs a refresh.

I wonder if you could be persuaded to submit a new revision
in light of these two points?

	Sean.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 19 May 2003 14:31:07 +0859 ()

Sean;

> And me.

Oh, yes. Thank you and several others.

> However, two things stand out:
> 

Yes, of course.

In addition, I answer your questions in this mail (as, in your
mail, they are located after an lengthy discussion and summary
of my draft, I have overlooked to answer them) in this mail.

>     How does a host know its address?
> 
>     That is, how does a host learn what set of path-indicators
> _can_ (not should, can) be advertised during the initial
> handshaking of a new TCP connection (or thereafter)?

Your question should be about a set of addresses of its own, not
peer's.

Then, my assumption is, they is preconfigured, just as addresses
of hosts today, by hand or through DHCP. You can also say RA,
though I think it sucks. A more smart solution is to let IGPs
carry them.

After the initial hand shaking, mobility may modify the set.

>         How many path-indicators should MultihomedSender
>         announce to the Receiver?  Two?  More than two?
>         How many path-indicators will Receiver announce
>         back in reply to the Sender's SYN (which uses a
>         path-indicator from the DNS)?  

There should be reasonable maximum. Currently, we set it 8.

Please don't assume that we can't modify TCP, or its maximum
option length.

>         Next: change.  What happens on the host if
>         MultihomedSite multihomes to another network?
>         What happens if some time (days?) subsequently
>         MultihomedSite permanently disconnects from
>         LocalISPNumberOne?  If the answer is: the host
>         acquires via some protocol (or manual
>         configuration) a new path-indicator, who assigned
>         the path-indicator in the first place?

Upper level ISPs assign the path-indicator, which will be hand
configured to hosts, DHCP servers and, most importantly, DNS
servers.

Please don't say "automatic renumbering", which is known to
be impossible w.r.t. DNS entries.

>         Incidentally, any solution to this which does not
>         require changes to the current routing system is
>         also a general solution to site renumbering, which
>         is much-missed feature in IPv4 and IPv6, and
>         likely would be worthy of an RFC of its own.

As I wrote:

   However, to enable source address filtering to discard packets with
   source addresses not belonging to an ISP, it is useful to enable a
   host, not some intelligent intermediate router, select a source
   address compatible with an outgoing ISP.  For that purpose, intra
   domain routing protocols should maintain routing table entries with
   not only preference values of an external routes, but also proper
   prefixes to be selected for source addresses, if the entries are
   chosen by a host.

I don't preclude the possibility to change the current routing
system, though, in this case, it is entirely optional and you can
do it by hand.

But, remember that the impossible part of automatic renumering
is in DNS.

						Masataka Ohta