RE: [saad] About saad

"Michel Py" <michel@arneill-py.sacramento.ca.us> Thu, 16 October 2003 01:06 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 VAA01699 for <saad-archive@odin.ietf.org>; Wed, 15 Oct 2003 21:06:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9waZ-0002x3-Ht for saad-archive@odin.ietf.org; Wed, 15 Oct 2003 21:06:04 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G163jU011342 for saad-archive@odin.ietf.org; Wed, 15 Oct 2003 21:06:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9waZ-0002wr-CP for saad-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 21:06:03 -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 VAA01691 for <saad-web-archive@ietf.org>; Wed, 15 Oct 2003 21:05:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9waW-00067z-00 for saad-web-archive@ietf.org; Wed, 15 Oct 2003 21:06:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9waW-00067w-00 for saad-web-archive@ietf.org; Wed, 15 Oct 2003 21:06:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9waX-0002wA-EA; Wed, 15 Oct 2003 21:06:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9wa9-0002vd-B4 for saad@optimus.ietf.org; Wed, 15 Oct 2003 21:05:37 -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 VAA01685 for <saad@ietf.org>; Wed, 15 Oct 2003 21:05:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9wa6-00067e-00 for saad@ietf.org; Wed, 15 Oct 2003 21:05:34 -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 1A9wa5-00067R-00 for saad@ietf.org; Wed, 15 Oct 2003 21:05:33 -0400
Subject: RE: [saad] About saad
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 15 Oct 2003 18:05:03 -0700
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Message-ID: <DD7FE473A8C3C245ADA2A2FE1709D90B06C64F@server2003.arneill-py.sacramento.ca.us>
Thread-Topic: [saad] About saad
thread-index: AcOTaklFShz0yAcWRHGvvcuOhPbVugAFOLQw
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Geoff Huston" <gih@telstra.net>, <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

Marcelo / Geoff,

> marcelo bagnulo wrote:
> I don't think that the discussion should be focused on IPv6
> only a priori.

> Geoff Huston wrote:
> For me this area of consideration is somewhat orthogonal to
> the V4 / V6 considerations.

That's fine by me, but then we do have some work with the about text:

> We have specified an Internet that works, at the network
> layer, using relatively stable but not permanent identifiers
> for connection endpoints, which are allocated and
> administered using a topology dependent model, implying a
> service provider dependent model

For IPv4 this is untrue, as PI addresses are not allocated using a
topology dependent model and do not imply a server provider dependant
model.


> But we run into problems (the architecture doesn't quite
> fit when we try to address some scenarios encountered in
> real life: multihoming

Untrue for IPv4. The issue with IPv4 multihoming is a scalability issue:
the growth of the routing table (resulting in part from the announcement
of multihomed blocks) induces instability, which is not good. Possibly,
a protocol other than BGP4+ would have a lot less of a scalability
issue, so I don't consider this an architecture issue.


> assembling a local network without necessarily having to contact
> an ISP to obtain address space(e.g.,home net)

Not a problem with IPv4: we have RFC1918.


> Some proposed solutions are challenged in terms of: 
> providing referential integrity - how is referential 
> integrity maintained when identifiers are not globally 
> unique or are overloaded?

The answer to this is simple: either make the identifiers globally
unique, or manage that ambiguous identifiers never collide (or make the
collision risk extremely slow).


> 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.

Michel.


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