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
- [RAM] some draft proposed definitions RJ Atkinson
- Re: [RAM] some draft proposed definitions tom.petch
- Re: [RAM] some draft proposed definitions Peter Sherbin
- Re: [RAM] some draft proposed definitions Joel M. Halpern
- RE: [RAM] some draft proposed definitions Marcus Brunner
- Re: [RAM] some draft proposed definitions Scott W Brim
- RE: [RAM] some draft proposed definitions Joel M. Halpern
- Re: [RAM] some draft proposed definitions Noel Chiappa
- Re: [RAM] some draft proposed definitions Noel Chiappa
- Re: [RAM] some draft proposed definitions Mikko Särelä