[RAM] revised draft proposed definitions
RJ Atkinson <rja@extremenetworks.com> Mon, 11 June 2007 14:13 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 1HxkeS-0002Ut-8Y; Mon, 11 Jun 2007 10:13:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxkeQ-0002Ug-P1 for ram@iab.org; Mon, 11 Jun 2007 10:13:46 -0400
Received: from eastrmmtao105.cox.net ([68.230.240.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxkeQ-0002A4-DR for ram@iab.org; Mon, 11 Jun 2007 10:13:46 -0400
Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070611141345.PRWL8837.eastrmmtao105.cox.net@eastrmimpo01.cox.net> for <ram@iab.org>; Mon, 11 Jun 2007 10:13:45 -0400
Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id AEDl1X00P0pnMhQ0000000; Mon, 11 Jun 2007 10:13:45 -0400
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Transfer-Encoding: 7bit
Message-Id: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
To: ram@iab.org
From: RJ Atkinson <rja@extremenetworks.com>
Date: Mon, 11 Jun 2007 10:13:44 -0400
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Subject: [RAM] revised draft proposed definitions
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
Here is a revised draft proposal for terminology, with the goal being greater clarity of communication. This is still not fully cooked yet. No terminology will be perfect; the goal here is to come up with something that most folks can tolerate and that is "good enough" to clarify our discussions (here and in related fora such as the IRTF Routing RG). Thanks to Dino, Scott, and Joel for their offlist feedback, some of which is reflected below. One good question raised off-list is how to classify an IEEE MAC in this terminology. On the one hand, an IEEE MAC does not really have any location embedded inside it. IEEE MAC values belong to the end system interface and remain constant even if the interface's point of attachment changes (i.e. the end system moves location), so they could be called an Identifier. An IEEE MAC contains several items of information [Manufacturer prefix + scope bit (global/local) + multicast/unicast bit + end system value]. The "end system value" indirectly might imply when the system was manufactured, but is otherwise entirely opaque. On the other hand, the IEEE MAC is used directly (feed a Destination MAC into a table and get back which I/O port(s) to transmit it upon) to bridge frames within a layer-2 infrastructure. Yours, Ran Identifier: An object that is used only for identification, never for forwarding packets or determining location. Identifiers might exist at different protocol layers. For example, a fully-qualified domain name is one sort of Identifier. The EUI-64 in the low-order bits of an IPv6 address might be an Identifier, for example in an proposed protocol of the "8+8" class, though that would be a different kind of identifier than an FQDN. ID: Abbreviation for Identifier. See "Identifier" entry. Locator: An object that is used only for forwarding packets or determining location, never for identification. Address: An object that with mixed semantics, where it is sometimes used for identity and sometimes used for packet forwarding. Examples include, but are not limited to, IP addresses, which are sometimes used to forward packets and sometimes used for node identity (e.g. in TCP session state). LISP RLOC: An object used for forwarding packets in the LISP protocol proposal. This is typically for forwarding outside of an edge site. LISP EID: An object that has scoped location semantics (e.g. used for location when inside an edge site) and has end-to-end identity semantics. Since it has mixed semantics, this is a kind of address, rather than being a pure identifier. Scoped Locator: A locator that has non-global scope. Note that a scoped locator only has location semantics, never identification semantics. Scoped Identifier: An identifier with non-global scope. Note that a scoped identifier only has identity semantics, never location semantics. Identity: A possible property of an object. Addresses and Identifiers are examples of objects that have identity semantics. Identity can exist at multiple protocol layers. One might compose a transport- layer identity from an IP address and a TCP port number or from a node identifier and a TCP port number -- for example. Location: A possible property of an object. Addresses and Locators are examples of objects that have location semantics. Location also can exist at multiple protocol layers; most notably, a node typically has both a link-layer location and a congruent but distinct network-layer location at a given instant in time. Identifier/Locator split: A class of network protocol that has no addresses, and only has (pure) identifiers and (pure) locators. Proposals in the GSE/8+8 class of solution might be examples of this, depending on the details of the proposal. Multi-Address split: A class of network protocol where one type of address is used for forwarding in one portion of the internetwork and a different type of address is used for forwarding in a different portion of the internetwork. Simple NAT is not an example of a multi-address split, since the same *type* of address (IPv4 xor IPv6) is used in all routing domains. LISP might be an example of a Multi-Address split. EOF _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram
- [RAM] revised draft proposed definitions RJ Atkinson
- Re: [RAM] revised draft proposed definitions Eliot Lear
- Re: [RAM] revised draft proposed definitions Tony Li
- [RAM] Re: revised draft proposed definitions Stephane Bortzmeyer
- Re: [RAM] revised draft proposed definitions HeinerHummel
- Re: [RAM] Re: revised draft proposed definitions Brian E Carpenter
- Re: [RAM] revised draft proposed definitions Brian E Carpenter
- Re: [RAM] revised draft proposed definitions Russ White
- Re: [RAM] revised draft proposed definitions RJ Atkinson
- Re: [RAM] revised draft proposed definitions JFC Morfin
- Re: [RAM] Re: revised draft proposed definitions Scott W Brim
- Re: [RAM] revised draft proposed definitions Russ White
- [RAM] Re: revised draft proposed definitions Stephane Bortzmeyer
- Re: [RAM] revised draft proposed definitions Noel Chiappa
- Re: [RAM] revised draft proposed definitions Russ White
- Re: [RAM] revised draft proposed definitions Tony Li
- Re: [RAM] revised draft proposed definitions Michael