RE: [saad] About saad

"J. Noel Chiappa" <jnc@ginger.lcs.mit.edu> Thu, 16 October 2003 16:16 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 MAA08594 for <saad-archive@odin.ietf.org>; Thu, 16 Oct 2003 12:16:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAnC-00038U-OK for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 12:16:02 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GGG2xg012053 for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 12:16:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAnC-00038K-Kx for saad-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 12:16: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 MAA08583 for <saad-web-archive@ietf.org>; Thu, 16 Oct 2003 12:15:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAnB-0006LY-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 12:16:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAnB-0006LT-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 12:16:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAnB-00037v-EC; Thu, 16 Oct 2003 12:16:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAn8-00037R-KA for saad@optimus.ietf.org; Thu, 16 Oct 2003 12:15:58 -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 MAA08577 for <saad@ietf.org>; Thu, 16 Oct 2003 12:15:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAn7-0006LM-00 for saad@ietf.org; Thu, 16 Oct 2003 12:15:57 -0400
Received: from ginger.lcs.mit.edu ([18.26.0.82]) by ietf-mx with esmtp (Exim 4.12) id 1AAAn6-0006LJ-00 for saad@ietf.org; Thu, 16 Oct 2003 12:15:56 -0400
Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h9GGFsWB000449; Thu, 16 Oct 2003 12:15:54 -0400
Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h9GGFrgS000448; Thu, 16 Oct 2003 12:15:53 -0400
Date: Thu, 16 Oct 2003 12:15:53 -0400
From: "J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>
Message-Id: <200310161615.h9GGFrgS000448@ginger.lcs.mit.edu>
To: saad@ietf.org
Subject: RE: [saad] About saad
Cc: jnc@ginger.lcs.mit.edu
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>

    > From: "Michel Py" <michel@arneill-py.sacramento.ca.us>

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

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.
 

    >> 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 semantics of IPv4 and IPv6 addresses are basically identical. The only
difference is in the number of bits.

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

Well, I suppose the eventual "real" IPv6 multi-homing will have fixed this,
but if anyone's using "naive" IPv6 multihoming now - i.e. doing it like IPv4
does it, with a PI address (or a chunk of PA address which it advertises
globally - the two are indistinguishable technically) - it has exactly the
same scaling problem.

    > Possibly, a protocol other than BGP4+ would have a lot less of a
    > scalability issue, so I don't consider this an architecture issue.

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.

So, it *is* an architectural issue.


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

	Noel

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