Subject: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt]

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Dec 2003 09:26:31 +0100

fyi

-------- Original Message --------
Subject: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt
Date: Mon, 15 Dec 2003 15:29:00 -0500
From: [email-masked]
Reply-To: [email-masked]
To: IETF-Announce: ;

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Things MULTI6 Developers should think about
	Author(s)	: E. Lear
	Filename	: draft-lear-multi6-things-to-think-about-00.txt
	Pages		: 12
	Date		: 2003-12-15
	
This document specifies a set of questions that authors should be
prepared to answer as part of a solution to multihoming with IPv6.
The questions do not assume that multihoming is the only problem of
interest, nor do they demand a more general solution either.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-think-about-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-lear-multi6-things-to-think-about-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-lear-multi6-things-to-think-about-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 16 Dec 2003 10:32:16 +0100

Hi,

i think this draft will be useful

I have some additional questions for your consideration:

- Is the multi-homing solution IPv6 only or can it also be used with IPv4?
I know this is multi6, but it is probably interesting to know if the
solution can be applied to IPv4

- Does your solution applies to all type of sites?, for instance is your
solution suitable for very small sites? (does it requires an expert
administrator o very powerful equipment) is your solution siutable for very
large sites?

- About incremental deployment, i think that there are different ideas about
what incremental deployment means. So perhaps we could ask more specific
question (in addition) like:
     - Does your solution imposes changes outside the multi-homed site?
            - what do you need to change in the mh site? in particular if
you plug in a non upgraded IPv6 node, does it work properly? can it
communicate outside the mhsite? does it obtain multi-homing benefits?
     - Does your solution requires some global infrastructure to start
working? like a new global DNS like system, or it allows two upgraded nodes
to communicate with each other without any additional infrastructure

- If your solution preserves established communications, does it introduces
overhead? additional data? additional processing in the nodes? How does your
solution distributes the overhead? does it imposes additional overhead on a
per communication basis or a per node basis? does it imposes extra overhead
to all communications? does it imposes additional overhead for those
communications that don't suffer an outage along its path? does it only
imposes overhead after the outage?

- Impact od DNS, does you solution will impose an additional significant
stress to the DNS system? like how much more DNS queries are expected

Regards, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Brian E Carpenter
> Enviado el: martes, 16 de diciembre de 2003 9:27
> Para: Multi6
> Asunto: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt]
>
>
> fyi
>

Send a message to:
	[email-masked].
In the body type:

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 16 Dec 2003 17:00:57 +0100

> solution can be applied to IPv4

To be honest, I think this is not important right now. Let's solve the 
task at hand first. If we after that figures out that it works for IPv4 
as well, all the better.

> administrator o very powerful equipment) is your solution siutable for 

I think this might be a subjective judgment. Not sure it makes sense to 
take into account right now. But no strong feeling one way or the other.

> what incremental deployment means.

Maybe what we would need is to have each proposal include a description 
of how the proposal is implemented in a site/network?

- - kurtis -

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Dec 2003 17:17:39 -0800

Marcelo,

> solution can be applied to IPv4

This is worth while answering, for the reasons Tony mentions.  However, 
just because a solution works for v6 but not for v4 (say making use of 
the flow label that doesn't exist in v4) does not disqualify it as a 
right proper solution to the problem at hand.  As we've discussed in 
person and on the list, v4 is a bonus if we can get it.

> administrator o very powerful equipment) is your solution siutable for very

I think there is a related question I also failed to ask: what sort of 
support from upstreams and the registries does your solution require (if 
any)?

>      - Does your solution imposes changes outside the multi-homed site?

Right- that's in there (at least in part), but see above as well.

> communicate outside the mhsite? does it obtain multi-homing benefits?

This is a good question, and also was not clear in the draft.  If the 
mechanism can make use of stateless autoconfiguration or DHCP in some 
way to enable itself (at least at the conceptual level) that would be nice.

Here's a question: do nodes all know who they are?  How do they gain 
their knowledge?  Is there a change to dhcp or stateless 
autoconfiguration?  If so, describe.

> to communicate with each other without any additional infrastructure

that's also in there.

> imposes overhead after the outage?

Your question was a bit more general than what I wrote.  I talked about 
packet expansion, but I did not talk about exchanges that might add 
latency, and that will need to be added in the next version (I'll put it 
out the first week in January).
> stress to the DNS system? like how much more DNS queries are expected

The number of queries were not addressed; this is a good question, 
especially if the mechanism will screw up normal DNS caching semantics 
in some way, or othrewise will be screwed up by those same semantics.

Happy Holidays,

Eliot