Re: [RAM] some draft proposed definitions

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 11 June 2007 13:40 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxk7s-0000ze-U7; Mon, 11 Jun 2007 09:40:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxk7r-0000zX-5v for ram@iab.org; Mon, 11 Jun 2007 09:40:07 -0400
Received: from [2001:470:1:1:230:48ff:fe74:fd02] (helo=bender-mail.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxk7p-0004Bq-LO for ram@iab.org; Mon, 11 Jun 2007 09:40:07 -0400
Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id B05617DCB for <ram@iab.org>; Mon, 11 Jun 2007 06:39:59 -0700 (PDT)
Received: from JMHLap3.joelhalpern.com (jupiter.inet.qwest.net [67.133.255.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 1A7807DC9 for <ram@iab.org>; Mon, 11 Jun 2007 06:39:59 -0700 (PDT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 11 Jun 2007 09:39:55 -0400
To: ram@iab.org
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [RAM] some draft proposed definitions
In-Reply-To: <9027C973-70C4-437A-9182-986063D7C7A8@extremenetworks.com>
References: <9027C973-70C4-437A-9182-986063D7C7A8@extremenetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-Id: <20070611133959.1A7807DC9@bender.tigertech.net>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net
X-Spam-Status: No, hits=1.8 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, MSGID_FROM_MTA_ID
X-Spam-Level: *
X-Spam-Score: 1.8 (+)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

Looking at these definitions, and trying to think through more cases, 
I don't think that this actually captures the distinction, at least 
as I think of it.
And I suspect that issue is why people react differently to various 
proposals in which IDs are also used for forwarding.

Lets look at two closely related examples:
Is an IEEE 48 bit "address" really an identifier, a locator, or a 
hybrid.  As far as I can tell, it is strictly an identifier.  It is 
assigned to a particular thing in a way that has no regard to where 
that thing is in any topology.  However, being excessively clever 
engineers, we have then built solutions which allow us to forward 
packets based on that identiifers.  Sometimes even very large 
solutions.  (bridging in all its myriad forms.)  That usage does not 
change the nature of the field.
And before one argues that the MAC was layer 2, not layer 3, remember 
that OSI routing did exactly the same thing with the lower bytes of 
the NSAP within an area.  That potion was an identifier.  It stayed 
the same when the system moved (even if it moved between areas.)

Hence, I think the difference between an Identifier and a Locator is 
in the semantics, not in whether it can be used to deliver 
packets.  It doesn't seem to me that an identifier suddenly becomes a 
locator if in some region we choose to keep track of where the 
identifier can be found.  To take the extreme case, some researchers 
have proposed systems that would use topologically insensitive 
identifiers for routing on systems of the scale of the 
internet.   Without regard to the actually usability of  the specific 
solutions, I think those things used for the end-points would still 
be identifiers, even if the entire system were forwarding packets 
based on them. The bit strings in that case have no location 
semantics in any topology that I can find.

Yours,
Joel M. Halpern

At 12:12 PM 6/10/2007, RJ Atkinson wrote:
>Identifier:     An object that is used only for identification,
>                 never for forwarding packets or determining location.
>
>ID:             Abbreviation for Identifier.
>
>Locator:        An object that is used only for forwarding packets
>                 or determining location, never for identification.


_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram