Re: [saad] About saad

"James Kempf" <kempf@docomolabs-usa.com> Thu, 16 October 2003 15:31 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 LAA07124 for <saad-archive@odin.ietf.org>; Thu, 16 Oct 2003 11:31:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA5m-0008JZ-AL for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 11:31:11 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GFVAEp031955 for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 11:31:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA5m-0008JK-4m for saad-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 11:31:10 -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 LAA07092 for <saad-web-archive@ietf.org>; Thu, 16 Oct 2003 11:30:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAA5h-0005xs-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 11:31:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAA5h-0005xo-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 11:31:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA5d-0008I8-T2; Thu, 16 Oct 2003 11:31:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA4k-000866-Bk for saad@optimus.ietf.org; Thu, 16 Oct 2003 11:30:06 -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 LAA07048 for <saad@ietf.org>; Thu, 16 Oct 2003 11:29:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAA4j-0005xA-00 for saad@ietf.org; Thu, 16 Oct 2003 11:30:05 -0400
Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AAA4i-0005x6-00 for saad@ietf.org; Thu, 16 Oct 2003 11:30:05 -0400
Message-ID: <003201c393f9$008398f0$396015ac@dclkempt40>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Michel Py" <michel@arneill-py.sacramento.ca.us>, "Geoff Huston" <gih@telstra.net>, <saad@ietf.org>
References: <DD7FE473A8C3C245ADA2A2FE1709D90B06C64F@server2003.arneill-py.sacramento.ca.us>
Subject: Re: [saad] About saad
Date: Thu, 16 Oct 2003 08:20:14 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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: 7bit
Content-Transfer-Encoding: 7bit

IPv4 still has the node identifier v.s. routing locater conflation problem
for addresses, however.

            jak

----- Original Message ----- 
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Geoff Huston" <gih@telstra.net>et>; <saad@ietf.org>
Sent: Wednesday, October 15, 2003 6:05 PM
Subject: RE: [saad] About saad


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


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