RE: [saad] About saad

"Michel Py" <michel@arneill-py.sacramento.ca.us> Fri, 17 October 2003 04:38 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 AAA06329 for <saad-archive@odin.ietf.org>; Fri, 17 Oct 2003 00:38:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMNG-0004ud-Dy for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 00:38:02 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H4c2jX018877 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 00:38:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMNG-0004uO-8S for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 00:38:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06319 for <saad-web-archive@ietf.org>; Fri, 17 Oct 2003 00:37:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAMND-0006Ms-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 00:37:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAMND-0006Mo-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 00:37:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMNE-0004u2-Li; Fri, 17 Oct 2003 00:38:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMMi-0004lc-G6 for saad@optimus.ietf.org; Fri, 17 Oct 2003 00:37:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06315 for <saad@ietf.org>; Fri, 17 Oct 2003 00:37:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAMMf-0006Mk-00 for saad@ietf.org; Fri, 17 Oct 2003 00:37:25 -0400
Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1AAMMf-0006Md-00 for saad@ietf.org; Fri, 17 Oct 2003 00:37:25 -0400
Subject: RE: [saad] About saad
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Thu, 16 Oct 2003 21:36:54 -0700
Content-Transfer-Encoding: quoted-printable
Message-ID: <DD7FE473A8C3C245ADA2A2FE1709D90B06C662@server2003.arneill-py.sacramento.ca.us>
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Thread-Topic: [saad] About saad
thread-index: AcOUAM8sSjem6NP+Q7uWok2jqTQhgAAY8fYw
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>, <saad@ietf.org>
Content-Transfer-Encoding: quoted-printable
Sender: saad-admin@ietf.org
Errors-To: saad-admin@ietf.org
X-BeenThere: saad@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/saad>, <mailto:saad-request@ietf.org?subject=unsubscribe>
List-Id: Scope Addressing Architecture Discussion <saad.ietf.org>
List-Post: <mailto:saad@ietf.org>
List-Help: <mailto:saad-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/saad>, <mailto:saad-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Noel,

> J. Noel Chiappa wrote:
> IPv4 tries to make sparing use of PI addresses for *exactly* the
> same reasons as in IPv6 - too many will overload the routing.
> The only difference is that with its greater address space, IPv6
> has even *more* rope to hang itself with, if it starts handing
> out PI addresses.

Indeed. Which is why we should not create PI addresses for IPv6.
 

> The semantics of IPv4 and IPv6 addresses are basically identical.
> The only difference is in the number of bits.

No. the difference is that IPv4 does officially have PI addresses, when
IPv6 does not. It's a matter of hypocrisy for a large part, but here is
our quandary:

We can't have IPv6 PI the same way we have IPv4 PI (because then there
will be very little incentive to move away from IPv4+NAT, especially
when the predicted exhaustion of IPv4 is years ahead). But, if we don't
have PI addresses this leads us to PA specifics announced in the GRT,
NATv6, or both. To worsen the situation, the requirements to become a
LIR are weak, which creates de-facto PI addresses.

In other words: if we create IPv6 PI, we lose because then IPv6 would
indeed be no more than IPv4 with more bits, which in turn will induce
that nobody would buy it until the exhaustion of IPv4 becomes an urgent
problem. If we do not create IPv6 PI, the demand for it will pervert
other mechanisms such as announcing long PA prefixes (de-aggregation) or
prefixes issued from the proposed Hinden/Haberman draft that are not
aggregatable at all.

Lose/Lose.

The way out of this is to provide PI IDENTIFIERS carried on the network
using PA LOCATORS, which are aggregatable.


> A different routing algorithm/protocol might have a *one-time*
> improvement in overhead, but in the long run, the curve is going
> to have the same kind of shape. Having to track too many distinct
> destinations (which is roughly equivalent to "routing table size")
> will overwhelm *any* routing architecture.

I personally agree, but I will point out that there is a large and
rather silent camp that thinks we don't have a problem as long as we
ride Moore's law.


>> choosing between different identifiers for an object
>>                            ^^^^^^^^^^^
>> which has different "reachability" and the reachability
>> is context-dependent
>> Shouldn't "identifiers" above be "locators"? I vaguely assume that an
>> object can have multiple locators but should have only one
identifier.
 
> It all depends on what is meant by the term "identifier" here.
> (The document probably needs some editing for precision, etc.)
> If it means "a name used for end-end identification", it would be
> a problem; and I would like to understand what the architectural
> need is for multiple end-end names for a single end-end entity.
> If it means "address" or "locator", it ought to say so.

Given what I mentioned above, it can't mean "locator".

Michel.


_______________________________________________
Saad mailing list
Saad@ietf.org
https://www1.ietf.org/mailman/listinfo/saad