Subject: draft-hain-templin-ipv6-localcomm-03.txt

From: Fred Templin <[email-masked]>
Date: Fri, 24 Oct 2003 10:09:47 -0700

Hello,

A new version of the 'hain/templin' draft is now available (see below).
This version obsoletes the previous document named:

  "Goals for an Addressing Scheme to Support Local Communications within 
Sites"
  draft-hain-templin-ipv6-limitedrange-02.txt

Fred
[email-masked]

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: Goals for Local Communications within Sites
>	Author(s)	: T. Hain, F. Templin
>	Filename	: draft-hain-templin-ipv6-localcomm-03.txt
>	Pages		: 15
>	Date		: 2003-10-23
>	
>The IPv6 addressing architecture specifies global and local-use
>unicast addressing schemes, but provides no operational guidelines
>for their use. There is a perceived need for an addressing scheme
>that supports local communications within sites. Of special interest
>are 'active sites', e.g., sites that are intermittently-connected or
>disconnected from the global Internet, sites that frequently change
>provider points of attachment, sites that temporarily or permanently
>merge with other sites, multi-homed sites, etc. This memo will
>discuss goals for an addressing scheme to support local
>communications within sites.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-localcomm-03.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-hain-templin-ipv6-localcomm-03.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-hain-templin-ipv6-localcomm-03.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.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 27 Oct 2003 13:10:32 +0100 (CET)

I have some on draft-hain-templin-ipv6-limitedrange-02.txt
which appear to apply to the new draft even though it has removed
the explicit reference to the need for a local address format
from the title and abstract/intro.

The summary is that I think we need a discussion about the needs of
sites in general and these "active sites" in particular, but this
draft doesn't seem to do that. Details below.

Comments on draft-hain-templin-ipv6-limitedrange-02.txt

The document seems to make the case that there is a set of
interested goals and requirements related to "active sites",
and I agree that this is something that we need to understand
better.

But the document from the outset, and in every other paragraph,
assumes that any and all solutions to to making such sites work better
involve defining some local address space. As a result the document reads
as an attempt to justify a particular solution to the problem, and not
as a balanced attempt to understand the issues relating to such sites and
the goals related to making them work better.

Thus I think we instead need goals for "active sites" with local and 
global communication (taking into account that for different sites the 
relative importance of global and local communication is likely to be 
different).

For those that think that there can't exist solutions which don't use
a local address space I offer 4 different possible approaches where only 1
use local address space (and another uses local locators which are invisible
to the applications):
 - unique local addresses plus TBD mechanisms for name resolution (DNS)
   and application impact; a rather large TBD IMHO. See Keith's recent mail.
 - for sites which are naturally part of some larger site using
   Nemo (or just tunneling with delegated global addresses from the
   larger site) just work. This approach doesn't handle
   all types of active sites, but it doesn't seem to require any additional 
   standardizion - running DHCPv6 prefix delegation over IPv6-in-IPv6
   tunnels seems to be sufficient.
 - relying on some multi6 solution (see draft-nordmark-multi6-noid and
   draft-nordmark-multi6-sim as existance proof that such solutions can be 
   created, if nothing else [Thus this is not an endorsement that I think
   those particular approaches are the best.])
   by using global locators plus standard filtering, renumbering the *locators*
   on attachment in a new place (keeping the old locator prefix alive while
   the new locators are propagated). 
 - as above but also using unique local *locators* to make the locator
   renumbering smoother.  This introduces the need to be able to discover
   those local locators in addition to discovering the global locators.
I hope the above list shows that defining some unique local address space
is not the only approach to making "active sites" work better.

Is anybody interested in producing a document about "Issues and goals
for active sites" without assuming that the solution is some new address
space? 

FWIW I find it odd that while the multi6 problem statement is related to 
the overloading of location and identity in the IP address space (which
made sense 25 years ago) and folks are trying to figure out how
to add a layer of indirection to solve that problem, the local
address discussion is about overloading addresses with yet more functionality
and semantics.

   Erik

---

From: Fred Templin <[email-masked]>
Date: Mon, 27 Oct 2003 15:50:32 -0800

Erik,

>the goals related to making them work better.

We have received this particular comment many times and from
many different sources. The document has undergone significant
modifications based on specific comments in a best effort to eliminate
any perceived links to any specific solution alternative(s).

If you are still seeing the document as advocating a particular solution
alternative, please send specific text change suggestions as that is not
the document's intention.

>for active sites" without assuming that the solution is some new address

Yes - me. Defining issues and goals for active sites w/o assuming a
solution alternative is exactly what we are striving to accomplish in
the 'hain-templin' document. If you are not seeing this, please send
specific text change suggestions.

Fred
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Oct 2003 10:50:04 +0100 (CET)

> the document's intention.

Fred,

The question in my mind is not what one would change in the
document but instead what parts one could retain.
The problem is that the document was originally written as an argument
for why local addressing in general, and site-local addressing
in particular, was required.

Doing incremental edits to change the document to have a completely different
perspective isn't likely to be efficient. Better to start over with a blank
slate and import the part of the existing document that make sense with that
new perspective. (Just to make it clear, I think the document includes
many perceived important aspects desirable properties for active sites, but
the history of the documents colors things in ways that makes the document
confusing and not very succinct.)

Another high-order bit which I perhaps didn't make sufficiently explicit in
my note is that the document is completely silent on the desirable
properties of global communication for these active sites.
I think we can assume that the importance of global communication
is greater than zero; those sites which don't need any global communication
aren't part of the Internet even though they use IP technology (and IPv4
is fine for them as long as long as they have only a few hundered million nodes
or so :-)

Thus I think it makes sense to describe the desirable properties for global
communication as well even though different individual sites will place
different relative importance on local and global communication;
in some cases local will be much more important and in other cases
global might be the more important one.

  Erik

---

From: Fred Templin <[email-masked]>
Date: Tue, 28 Oct 2003 09:47:47 -0800

>in particular, was required.

The above statement is false. The document in question came about
by combining two earlier works of the co-authors. The earlier works
are still in the I-D repository - see for yourself:

 http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-01.txt
 http://www.ietf.org/internet-drafts/draft-templin-lsareqts-00.txt

>is fine for them as long as long as they have only a few hundered million nodes

Global communications are out of scope for the document in question;
a quick read of the document title makes this abundantly clear. Of course,
support for global communications is vitally important, but that is a topic
for another document.

>global might be the more important one.

If you want a document on global communications goals for sites,
by all means go ahead and write one. We already have a document
on local communications goals for sites.

Fred
[email-masked]