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

Erik Nordmark <Erik.Nordmark@sun.com> Mon, 27 October 2003 12:11 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08646 for <ipv6-archive@odin.ietf.org>; Mon, 27 Oct 2003 07:11:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6DN-0002O6-2l for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:11:18 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RCBGi5009165 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 07:11:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6DM-0002NY-Mu for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 07:11:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08584 for <ipv6-web-archive@ietf.org>; Mon, 27 Oct 2003 07:11:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6DI-0003mJ-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:11:12 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE6DH-0003mD-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 07:11:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6D9-0002Bi-4i; Mon, 27 Oct 2003 07:11:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6Cx-0002Ab-JI for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 07:10:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08560 for <ipv6@ietf.org>; Mon, 27 Oct 2003 07:10:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6Ct-0003lo-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:10:47 -0500
Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AE6Cs-0003ll-00 for ipv6@ietf.org; Mon, 27 Oct 2003 07:10:46 -0500
Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9RCAk5u007237; Mon, 27 Oct 2003 05:10:47 -0700 (MST)
Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9RCAjS29914; Mon, 27 Oct 2003 13:10:46 +0100 (MET)
Date: Mon, 27 Oct 2003 13:10:32 +0100
From: Erik Nordmark <Erik.Nordmark@sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@sun.com>
Subject: Re: draft-hain-templin-ipv6-localcomm-03.txt
To: Fred Templin <ftemplin@iprg.nokia.com>
Cc: ipv6@ietf.org
In-Reply-To: "Your message with ID" <3F995CDB.2080406@iprg.nokia.com>
Message-ID: <Roam.SIMC.2.0.6.1067256632.8078.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
Sender: ipv6-admin@ietf.org
Errors-To: ipv6-admin@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Id: IP Version 6 Working Group (ipv6) <ipv6.ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>

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



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------