[rrg] LEIDs, SPI & ordinary IP addresses as both IDs & Locs
Robin Whittle <rw@firstpr.com.au> Fri, 19 February 2010 02:09 UTC
Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CEE828C0E2 for <rrg@core3.amsl.com>; Thu, 18 Feb 2010 18:09:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.727
X-Spam-Level:
X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P694HHEsu87D for <rrg@core3.amsl.com>; Thu, 18 Feb 2010 18:09:42 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 23D9B3A67AC for <rrg@irtf.org>; Thu, 18 Feb 2010 18:09:41 -0800 (PST)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 412C0175E32; Fri, 19 Feb 2010 13:11:23 +1100 (EST)
Message-ID: <4B7DF349.1060807@firstpr.com.au>
Date: Fri, 19 Feb 2010 13:11:21 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Subject: [rrg] LEIDs, SPI & ordinary IP addresses as both IDs & Locs
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Feb 2010 02:09:43 -0000
Short version: LISP EIDs, Ivip SPI addresses are global unicast IP addresses which - like any other global unicast IP address used by a host - function as both host Identifiers and as Locators, both with global scope. Its just that LEIDs, SPI (Scalable PI) addresses or whatever are part of the "edge" subset of the address space, created by the Core-Edge (addresses) Separation (CES) architecture which involves them having a different method of encoding their Locator semantics. This different method is interpreted according to a new algorithm performed by special routers also provided by the CES architecture: ITRs. To get to the ITR, the usual routing algorithm is used. Once decapsulated at the ITR, the usual algorithm can take the packet to the destination host. Hi Noel, Further to your discussion (msg06064) of Lixia's alternative LISP critique, you wrote: >> Thus "EID" in LISP is not a host identifier, but IP addresses used >> within a site for packet delivery. > > We keep going around and around on this. > > The LEID is used to identify the host, and does so across a global > scope - in both sense of the term - i.e. it is the same everywhere > in the network, and it is also used for that purpose everywhere in the > network. Hosts _everywhere_ in the Internet will _always_ use that > identifier for communicating with the host named by that LEID. Yes. A LEID (LISP EID) or an Ivip SPI address is exactly the same as any other global unicast IP address in this respect. A host may have one or more global unicast IP addresses and (except for anycast and fancy things which spread load over back-end servers) each unique global unicast IP address identifies a single host. When a host addresses a packet to a given global unicast IP address - including an LEID or an SPI address - then, assuming there is a host which uses this address, two things can be assumed: 1 - The packet will probably be delivered - but may be dropped. 2 - If the packet is delivered to a host, it will be to the one host which this IP address identifies, not any other. > So it _is_ a host identifier, and is used for _more_ than just > 'packet delivery ... within a site'; the wording above is, at best, > misleading. I agree. > In _some_ cases it _also_ has location semantics, with local scope > (i.e. that location information is _not_ useful outside that local > scope - even though it _is_ unique). However, in other cases it > doesn't. This is where we disagree. I am sure that the LEID always has Locator semantics. How else does a packet with a LEID in its destination field get delivered reliably to the correct destination host, from anywhere in the world? Packets addressed to global unicast IP addresses - including LEIDs or Ivip SPI addresses - all get delivered to their destination host based on the destination IP address. The packet carries no other information to aid the routing system determine how to handle the packet. In the case of an ordinary global unicast IP address - one not covered by the Core-Edge Separation architectures ITR, ETR, mapping system etc. (that is, not in the "edge" subset - not an LEID or an SPI address) then the mechanism by which the routing system gets the packet to the destination host is in principle the same at every router: Algorithm 1 Look at the destination IP address from the left until a match is found with the most specific prefix in the FIB, and use the information stored there to determine what to do with the packet - which will be forwarding out one or another interface, including via a LAN to another router, or eventually to the destination host. Here the Locator role of the IP address is being implemented in a particular manner, but this is not the only way the IP address could be used as a Locator. In principle, the above approach could be used by all routers in the world, down to a /32 match, but this would be unscalable. In practice, routers which match prefixes longer than /24 are only found in the local routing system of the destination network, since by convention, prefixes longer than /24 are not propagated in the IPv4 DFZ. >From a host HA in one end-user network (EUN-A) to another host HB in another EUN-B, both with different ISPs: From HA in EUN-A to ISP-A: Alg. 1 In ISP-A to DFZ: Alg. 1 Across DFZ to ISP-B: Alg. 1 In ISP-B to EUN-B: Alg. 1 In EUN-B to HB: Alg. 1 In the case of a packet whose destination address is an LEID or SPI address, Algorithm 1 is followed by conventional routers until the packet arrives at an ITR. Then a completely different algorithm is used to implement the Locator function of this destination IP address: Algorithm 2 The ITR recognises the destination address is an LEID or SPI address and does a mapping lookup using the full address (assuming it has not got mapping already cached). The mapping arrives, and this enables the ITR to decide which ETR to tunnel the packet to. The mapping system can work (for IPv4) down to a resolution of a single IPv4 address - so all 32 bits can be used for the IP address's role as a Locator. This is scalable since the mapping system doesn't burden the DFZ control plane. Once the packet arrives at the ETR and is decapsulated, the ETR has more specific routes for its destination address which use Algorithm 1, as noted above, to deliver the packet to the destination host. Assuming ITR and ETR functions are performed in the CE routers of both EUNs: From HA in EUN-A to ITR: Alg. 1 In the ITR: Alg. 2 which generates a packet with the ETR's address in the destination field. This packet is handled by: (From ITR, trough ISP-A to DFZ: Alg. 1) (Across DFZ to ISP-B: Alg. 1) (In ISP-B to ETR: Alg. 1) ETR decapsulates original packet. From ETR, through EUN-B to HB: Alg. 1 CES architectures such as LISP and Ivip do not in any way alter the current naming model of IPv4 or IPv6: Role Level Conventional IP & with CES Text name <---- FQDN Identifier <---] IP address Locator <---] CES architectures create a subset of the global unicast address - the "edge" subset, known as EID space in LISP or SPI space in Ivip - in which the Locator functionality of the IP address is implemented differently by certain new routers: ITRs. The LIED or SPI address is still fully compliant with the two-level naming model of IPv4 or IPv6. LISP, Ivip and other CES architectures do not implement "Locator/Identifier Separation". All CEE (Core-Edge Elimination) architectures do - they have having two separate objects, two separate items in packets, one to perform the Identifier role and the other to perform the Locator role. > The LEID does not _cleanly_ correspond to either an endpoint > identifier or an interface locator, because depending on the > circumstances, and because of the backwards compatibility, it can in > some cases have mixed semantics. I don't think "backwards compatibility" or "mixed semantics" are accurate descriptions for what I am trying to explain. Because LISP introduces ITRs which use the new Algorithm 2 to interpret the LEID bits in a way which differs from the traditional router approach of Algorithm 1. It is arguably "architecturally unclean" to introduce this, and ITRs, into the Internet - but compared to introducing CEE architectures with their Locator/Identifier Separation naming model, I argue (msg05865) that LISP, Ivip etc. is is much cleaner and better. > Asking whether an LEID is 'an identifier, or a locator' is thus akin > to asking if an octagon is a square or a circle. Indeed - a LEID is like any other global unicast IP address. It can be used to get a packet to a destination host and is playing the roles of both Identifier and Locator. Its just that the Locator role of an LEID or SPI address relies on ITRs, ETRs and the mapping system, since ordinary routers don't do Algorithm 1. > If you absolutely _have_ to stuff it into either the round hole or a > square hole, I'd say the 'endpoint identifier' one is a better fit, > because it _always_ has identification semantics on a global scope, > whilst on the other hand, i) in _no_ circumstances does an LEID ever > have global location semantics (which is what I think of a locator as > having), and ii) in _some_ circumstances it has no location semantics > _at all_. As a card-carrying member of the Octagon Liberation Front, I urge you not to play along with the oppressors by trying to comply with their conceptual framework. > How can a thing which _always_ has endpoint identity semantics, and > sometimes has _no_ interface location semantics, be an 'address'? Sure it can be an "address". It has location semantics, but they are only able to be interpreted by an ITR using Algorithm 2. - Robin
- [rrg] LEIDs, SPI & ordinary IP addresses as both … Robin Whittle
- Re: [rrg] LEIDs, SPI & ordinary IP addresses as b… Noel Chiappa
- Re: [rrg] LEIDs, SPI & ordinary IP addresses as b… Robin Whittle
- Re: [rrg] LEIDs, SPI & ordinary IP addresses as b… Noel Chiappa
- Re: [rrg] LEIDs, SPI & ordinary IP addresses as b… Robin Whittle
- Re: [rrg] LEIDs, SPI & ordinary IP addresses as b… Templin, Fred L
- Re: [rrg] LEIDs, SPI & ordinary IP addresses as b… Templin, Fred L
- Re: [rrg] LEIDs, SPI & ordinary IP addresses as b… Noel Chiappa
- Re: [rrg] LEIDs, SPI & ordinary IP addresses as b… Templin, Fred L
- Re: [rrg] LEIDs, SPI & ordinary IP addresses as b… Robin Whittle