Subject: [rrg] LISP does not implement Locator / Identity Separation

From: Robin Whittle <[email-masked]>
Date: Mon, 08 Mar 2010 14:00:30 +1100

Short version:   Why does anyone think that LISP implements the
                 the Locator / Identity Separation naming model?

                 "Locator / Identity Separation" doesn't describe
                 anything but this naming model.

                 Loc/ID Separation is a complete change to the
                 way hosts communicate, but LISP and other CES
                 architectures support hosts communicating with
                 today's IPv4/6 naming model in which the roles
                 of Identifier and Locator are both performed
                 by the one IP address.

                 An EID address is not an Identifier and an RLOC
                 address is not a Locator.  Both kinds of address
                 are like any IP address - they play the roles of
                 both Identifier and Locator.  ITRs use a different
                 algorithm for EID destination addresses.  All
                 other routers and all hosts make no distinction
                 between EID and RLOC addresses.

Hi Noel,

In the "Re: [rrg] Why won't supporters of Loc/ID Separation (CEE)
argue their case?" you wrote:

>> (LISP is misnamed - it does not involve Loc/ID Separation.)
>
> Yes, it just has a mapping database to waste cycles and increase
> complexity!
>
> Whatever.

The LISP mapping system accepts an "edge" (EID) address and returns
the "core" (RLOC) address of the one or more ETRs which can deliver
packets to the destination network.  This is not a question of
Identifiers and Locators - it is "edge" addresses and "core" addresses.

Please take a look at

   CES & CEE are completely different (graphs)
   http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html

   Today's "IP addr. = ID = Loc" naming model should be retained
   http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html

LISP is a Core-Edge Separation architecture.  It creates a separate
subset of global unicast address space ("edge" space, AKA "EID"
space) which can scalably be used by end-user networks for
portability, multihoming and inbound TE.  The remainder of the global
unicast space is known as "core" (AKA "RLOC").

Whether a host is on an EID or RLOC address, its IP address still
functions both as this host's Identifier and as the routing Locator
which the routing system uses to get the packet to the host.  In the
case of an EID address in the destination field of a packet, ITRs use
a different algorithm to the usual one used by all other routers to
transport the packet towards its destination.  This is described in:

  Re: LEIDs, SPI & ordinary IP addresses as both IDs & Locs
  http://www.ietf.org/mail-archive/web/rrg/current/msg06082.html

Do you agree that all the CEE architectures implement the Loc/ID
Separation naming model?

Do you believe that LISP implements this model?  If not, then what
other sense of "Locator / Identifier Separation" do you believe LISP
implements?

  - Robin

Search engine bait:   LISP is misnamed.  The "Locator / Identifier
Separation Protocol" (LISP) is a misnomer.

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 7 Mar 2010 21:46:16 -0800

>               An EID address is not an Identifier and an RLOC

It is an identifier. It is used by the TCP and UDP socket layer. Just  
because an EID is also a scoped locator inside of a site, does not  
preclude it from being an identifier.

>                 between EID and RLOC addresses.

LISP does separate ID and locator because you can keep an EID fixed  
with a system, maintaining session continuity, while changing the  
locator associated with the EID.

Dino

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 8 Mar 2010 10:34:01 +0200

Hello Dino

Just a remark that in the mapping system discussions in the lisp list
the strong sentiment is that EIDs must be allocated  and administered as
EID blocks to guarantee any efficiency and scalability. If the
identities are coming from blocks that are allocated to given
enterprises, then what happens when one of devices or a small remote
site joins to an other enterprise in an different EID block? Renumbering
of EIDs maybe? How portable are the EIDs at the end of the day depends
on the mapping system structure and scalability.  I would say that EIDs
are independent from locators for sure, but not from their allocation
scheme that ties them to topology. 

- Hannu
 
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Dino Farinacci
>Sent: Monday, March 08, 2010 07:46
>To: Robin Whittle
>Cc: RRG; Noel Chiappa
>Subject: Re: [rrg] LISP does not implement Locator / Identity 
>Separation
>
>It is an identifier. It is used by the TCP and UDP socket 
>layer. Just because an EID is also a scoped locator inside of 
>a site, does not preclude it from being an identifier.
>
>LISP does separate ID and locator because you can keep an EID 
>fixed with a system, maintaining session continuity, while 
>changing the locator associated with the EID.
>
>Dino
>
>_______________________________________________
>rrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Damien Saucez <[email-masked]>
Date: Mon, 8 Mar 2010 09:53:19 +0100

Hannu,

> scheme that ties them to topology. 

We have to think more about this question. IMHO, there is no real scalability
problem for the mapping system when a company has several prefixes that
cannot be aggregated. Indeed, this is not because two prefixes belong to
the same company that the path to get the mapping via the mapping system
must be the same. For example, if a company has the prefix A.1.2.3 and the
prefix B.4.5.6, and if ALT is deployed like a tree, the map request will go
to A, then A.1 then A.1.2 and finally A.1.2.3 for the first prefix and to B,
B.4, B.4.5 and B.4.5.6 for the second prefix. If ALT use aggregation, Only
A and B need to be announced to the top of the tree. In this case, we even
have a good scalability for the mapping system as the requests for a company
may follow very different path in the mapping system.
Now, if we are thinking about the cache, I don't believe that it will cause so
many troubles. Of course, you will have to install A.1.2.3 and B.4.5.6 in the
cache for the company, but as stated by Joel, it is likely that the prefixes will
be uncorrelated in term of traffic (except in the UCL use case I sent
yesterday), therefore, you will probably, on the long term, only have one entry,
not both. One big advantage of LISP is that you mapping table scales with
your traffic, not with the size of the Internet.

To conclude, having one company with non aggregatable prefixes will
not cause (?) deaggragation in the mapping system and thus should not
cause scalability troubles.

Cheers,

Damien Saucez

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 8 Mar 2010 11:22:29 +0200

Hello Damien and others

I am not sure if I can follow this: 
 
"...big advantage of LISP is that you mapping table scales with your
traffic, not with the size of the Internet."
This is true for the ITR caches, but not for the mapping system as it
needs to provide mappings to all EIDs. So the size of the mapping system
is a function of EIDs, not the traffic. If an EID wants to be globally
reachable it needs to have an entry in the global mapping system,
irrespective of the traffic.

The block/prefix based aggregation will break over the time if the
assignments are not reallocated. This has happened with the existing
prefix based allocations and will happen again. I can not see other way.
If  end devices do not renumber, then the mapping system needs to
reconstruct its structure, or then the blocks will deaggregate. 

Migration of a single subsidiary from an enterprise to an other is not a
big issue, I can see that, but over the time migration of small sites
seems to be quite common. They keep on coming and going. This will lead
to the extreme case that there would be long prefixes at the very top of
the mapping system if we stick to the original allocation. And then all
of the map-requests will go through the top of the mapping system. At
least with the DNS of today that is not the most ideal case.

Best regards
Hannu 

>From: ext Damien Saucez [mailto:[email-masked]] 
>Sent: Monday, March 08, 2010 10:53
>To: Flinck, Hannu (NSN - FI/Espoo)
>Cc: RRG
>> the strong sentiment is that EIDs must be allocated  and 
>administered 
>> as EID blocks to guarantee any efficiency and scalability. If the 
>> site joins to an other enterprise in an different EID block? 
>> Renumbering of EIDs maybe? How portable are the EIDs at the 
>end of the 
>> day depends on the mapping system structure and scalability. 
> I would 
>> say that EIDs are independent from locators for sure, but not from 
>> their allocation scheme that ties them to topology.
>
>We have to think more about this question. IMHO, there is no 
>real scalability problem for the mapping system when a company 
>has several prefixes that cannot be aggregated. Indeed, this 
>is not because two prefixes belong to the same company that 
>the path to get the mapping via the mapping system must be the 
>same. For example, if a company has the prefix A.1.2.3 and the 
>prefix B.4.5.6, and if ALT is deployed like a tree, the map 
>request will go to A, then A.1 then A.1.2 and finally A.1.2.3 
>for the first prefix and to B, B.4, B.4.5 and B.4.5.6 for the 
>second prefix. If ALT use aggregation, Only A and B need to be 
>announced to the top of the tree. In this case, we even have a 
>good scalability for the mapping system as the requests for a 
>company may follow very different path in the mapping system.
>Now, if we are thinking about the cache, I don't believe that 
>it will cause so many troubles. Of course, you will have to 
>install A.1.2.3 and B.4.5.6 in the cache for the company, but 
>as stated by Joel, it is likely that the prefixes will be 
>uncorrelated in term of traffic (except in the UCL use case I 
>sent yesterday), therefore, you will probably, on the long 
>term, only have one entry, not both. One big advantage of LISP 
>is that you mapping table scales with your traffic, not with 
>the size of the Internet.
>
>To conclude, having one company with non aggregatable prefixes 
>will not cause (?) deaggragation in the mapping system and 
>thus should not cause scalability troubles.
>
>
>Cheers,
>
>Damien Saucez
>
>> 
>> - Hannu
>> 
>layer. Just

---

From: Robin Whittle <[email-masked]>
Date: Mon, 08 Mar 2010 20:41:18 +1100

I am replying to Dino and Hannu.  Damien's reply concerned how the
ALT network would work - not the question of whether LISP implements
the Locator / Identity Separation naming model.

Hi Dino,

You wrote:

> It is an identifier. It is used by the TCP and UDP socket layer.
> Just because an EID is also a scoped locator inside of a site, does
> not preclude it from being an identifier.
>
>>   address is not a Locator.

OK - I was trying to be brief.  A better sentence would have been:

   An EID address is not only an Identifier and an RLOC address is
   not only a Locator.

My next sentence states this clearly:

>>   Both kinds of address are like any IP address - they play the
>>   roles of both Identifier and Locator.

though I should have written "any global unicast IP address".

>>   ITRs use a different

You can call an EID an "Identifier" but that doesn't make it so - EID
addresses are Identifiers and Locators at the same time. (msg06082)

An EID is just as much a Locator and an Identifier as any other kind
of global unicast address.  The only difference is that ITRs use a
different algorithm in handling packets with EID addresses in the
destination field than the do if the address is an RLOC.

"RLOC" addresses are the "core" set of global unicast addresses -
what is left after you "separate" the a new subset of scalable "edge"
space, which in LISP is called EID space.

You can call this "different Locator semantics" if you like, but that
second algorithm is only found in ITRs.  Hosts and all other router
treat an EID address with exactly the same algorithms as they do an
RLOC address.  They have no awareness of the EID/RLOC distinction.

An RLOC address used by a host or router is just like any other
global unicast IP address - it is both an Identifier and a Locator of
that host or router.  When you specify an ETR address in mapping for
an EID prefix, you are supplying a global unicast address (from the
RLOC subset) to tell ITRs which ETR to tunnel the packet to.  That is
part of the new algorithm which ITRs use for implementing the EID
destination address's Locator functionality.  The address of the ETR
is only a Locator for some EID-using host or network in terms of this
second algorithm which does the ITR to ETR tunneling part of
delivering the packet.  Where the host or network is actually found,
is a separate matter.  Typically they are close to the ETR, but they
are not exactly at the ETR.

Hannu, you wrote:

> EID blocks to guarantee any efficiency and scalability. 

I think this is because all EID addresses must be covered by a prefix
advertised by PTRs (Proxy Tunnel Routers).  LISP has no name for such
a prefix, but Dino recently referred to it as a "coarse" prefix.

As long as, in general, each "coarse" prefix covers the address space
of multiple separate EID prefixes, then routing scalability is
achieved, because without LISP each such EID prefix would need to be
advertised separately in the DFZ to achieve the same benefits to
end-user networks (portability, multihoming and inbound TE).

In Ivip, this "coarse" prefix is called a MAB - Mapped Address Block.

> If the

This can be handled by LISP by making that host's EID address a
separate EID prefix and mapping it to the ETR(s) of the network it is
located within.  Of course, that network needs to have its routing
system handle that EID prefix, because the host uses that address for
sending and receiving packets.

So EID addresses are perfectly portable to any ISP where you can run
an ETR, provided you can put them in EID prefixes.  With IPv4 LISP,
as far as I know, EID prefixes go to /32, so any amount of division
is possible.   It might be messy, for instance, to make a single IPv4
EID have a separate EID prefix if it was in the middle of an existing
EID prefix.   If it was the 09 address in a 16 IPv4 address /28
prefix, then there would need to be a bunch of separate EID prefixes
to make up the full 16 addresses:

   0 -  7    /29 EID prefix mapped to ETR N.
   8         /32 EID prefix mapped to ETR N.
   9         /32 EID prefix mapped to ETR Z.
  10 - 11    /31 EID prefix mapped to ETR N.
  12 - 15    /30 EID prefix mapped to ETR N.

Ivip's micronets use arbitrary starting points and have integer
lengths, so this could have been done in three micronets:

   0 -  8    Micronet A mapped to ETR N.
   8         Micronet B mapped to ETR Z.
   9 - 15    Micronet C mapped to ETR N.

> Renumbering

The allocation arrangement for EIDs has nothing to do with topology,
since any EID address or prefix of addresses can be mapped to any ETR.

 - Robin

---

From: Damien Saucez <[email-masked]>
Date: Mon, 8 Mar 2010 11:05:35 +0100

Hannu,

> irrespective of the traffic.

As I said, the size of your mapping table scales with the number of
organisation you have to contact. Except in case of scans, most of the
organizations only contact a small subset of the total number of
organizations that make the Internet being what it is. Of course, this
may not be the best property for some entities, but on average, 
scaling with your use should not be too bad.

If you really take care of how you build the mapping system (and
deploy it), you can make sure that you can do very aggressive 
aggregation and thus keep the mapping system "routing table"
small. A correct deployment of the mapping system should also
limit the load on each link of the mapping system. However, this
last point is not yet clear and we have to investigate a bit more.

Therefore, I would says that the size of the mapping system is not
a function of the number of EIDs, but a function of the hierarchy you
are willing to have. Of course, you will have a lot of leaves, but only
the direct parent of a leaf must know the existence of this leaf.

> assignments are not reallocated.
Why?
> This has happened with the existing
> prefix based allocations and will happen again.

The mapping system is only used for the control plane, so why do
you need to absolutely reallocate?

> I can not see other way.
I do not follow you? The cache, yes, it needs to do some kind of 
compression if too many entries have to be installed, but again, in
practice, you will have to scale to your traffic, not the Internet, you
can thus provision your routers accordingly.

> least with the DNS of today that is not the most ideal case.

I am not sure to understand the problem. A well design mapping system
should not take care of the number of mappings. Having a lot of prefixes
for the same entity will generate a lot of different mappings, but, the overall
mapping system does not take care about this. I see the mapping system
as a set of pointer, each node point you to a more specialized node until
you arrive a node able to provide you the mapping. So that, a node only
need to know what is under the responsibility of its neighbors. This is
true that in a mapping system like NERD we will have scalability troubles
in the case of a lot of small mappings, but ALT will not suffer it is correctly
deployed.

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 8 Mar 2010 22:53:50 -0800

> administered as

That is not my sentiment. ;-)

A site may have to request more EID-prefix space later after it  
perhaps uses all its addresses. So the entire set of EID-prefixes may  
not be in a power-of-2 block. But that doesn't mean the ALT cannot  
scale. The ETRs just register each EID-prefix to the map-servers that  
are injecting covering routes into the ALT.

> of EIDs maybe? How portable are the EIDs at the end of the day depends

No, no renumbering required. Plus we want people to use their existing  
PI or PA prefixes as EID-prefixes when they convert to LISP.

For IPv6, the situation will be much better. Because large enough  
blocks can be allocated so there most likely will be a single EID- 
prefix.

> scheme that ties them to topology.

EIDs are not tied to topology. That is the whole point. They are  
assigned to devices and stay fixed. This way, they can move if mobile  
or they can stay the same when sitting at a stationary site that  
changes service providers.

An EID is a network layer name that doesn't ever change. The name to  
EID mapping in DNS never needs to change. The moving lever is the  
mapping of EID to RLOC-set via the LISP mapping database.

Dino

---

From: Damien Saucez <[email-masked]>
Date: Tue, 9 Mar 2010 09:25:48 +0100

Hannu, Dino,
On 09 Mar 2010, at 07:53, Dino Farinacci wrote:

> A site may have to request more EID-prefix space later after it perhaps uses all its addresses. So the entire set of EID-prefixes may not be in a power-of-2 block. But that doesn't mean the ALT cannot scale. The ETRs just register each EID-prefix to the map-servers that are injecting covering routes into the ALT.
> 

Completely agree, we can imagine two map-servers, one responsible of A/a and one responsible of B/b. If you have A.1.2/p, just register with the first Map-server. If you have B.3.4/q, register to the second server. In the ALT, only A/a and B/b will be announced.

> No, no renumbering required.

No renumbering, except if you need all your hosts within the same prefix, but why would you need this?

> Plus we want people to use their existing PI or PA prefixes as EID-prefixes when they convert to LISP.

Ow, that's interesting, it is the first time you write it, isn't it? Ok for PI, but don't you think that reusing the current PA as EID is a good idea?

> For IPv6, the situation will be much better. Because large enough blocks can be allocated so there most likely will be a single EID-prefix.
> 

Sure, but we do not really need this aggregation, what we need is to keep the ALT aggregated, which is orthogonal to keeping the sites aggregated.

> EIDs are not tied to topology. That is the whole point. They are assigned to devices and stay fixed. This way, they can move if mobile or they can stay the same when sitting at a stationary site that changes service providers.
> 
> An EID is a network layer name that doesn't ever change. The name to EID mapping in DNS never needs to change. The moving lever is the mapping of EID to RLOC-set via the LISP mapping database.
> 

Maybe they are not given forever to hosts, but IMHO, EID prefixes are given to the networks almost forever, like today PI prefixes.

Damien Saucez

---

From: Scott Brim <[email-masked]>
Date: Tue, 09 Mar 2010 14:10:17 -0500

>                  between EID and RLOC addresses.

Give up on the names and look at how things are used.  As to whether
something "is" an identifier or not, the main question is NOT whether it
is sometimes used by forwarding functions (forwarders already use
anything and everything they want to make forwarding decisions), but
whether its association with a particular endpoint (at some layer) is
independent of changes in topology.

In the case of LISP the answer is not clear because it depends on use.
Potentially it can be topology-independent, but it is expected to be
used by forwarding in some site deployments, and a site might renumber
endpoints within an EID prefix if they move within that site.

But really, the thing to focus on is expected usage and real world usage.

---

From: Robin Whittle <[email-masked]>
Date: Wed, 10 Mar 2010 14:20:42 +1100

Short version:   One of the most important benefits of the "LISP"
                 architecture (or any other CES architecture) is that
                 it does *not* involve hosts using "Locator /
                 Identifier Separation".

                 I suggest renaming the "LISP" architecture - to
                 avoid the confusion caused by its current name.

Hi Scott,

> independent of changes in topology.

Both EID and RLOC addresses function as Identifiers - I am not
suggesting that an EID address doesn't.

I am suggesting that an EID address in the destination field also
acts as a routing Locator, since it is used in exactly the same way
as any other kind of address by all hosts and routers except ITRs.
ITRs use it as a routing locator too, but with a second algorithm
which uses the mapping system and tunneling.  I explained this in the
original message:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06190.html

I previously noted (msg06202) that the first sentence above should
have been:

> But really, the thing to focus on is expected usage and real world usage.

"Locator / Identifier Separation" is an enormously important
architectural concept which pre-dates "LISP".  It concerns hosts
dealing with other hosts by two separate types of object: Identifiers
to uniquely identify a host (though a host could have more than one
Identifier) and Locators to control how a packet gets to the
destination host.  It affects packet addressing structures, host
stacks and typically applications.  (Loc/ID Separation architectures
which attempt to support un-modified applications are pretty dodgy, I
think, since the applications make assumptions about the IP addresses
they use which are hard to support with the Loc/ID Separation stack
and network.)

Your architecture does not implement "Locator / Identifier
Separation" at a host level - which is what the term has always
referred to.  You could argue that this concept is at work in the
ITR's algorithm, but that is unimportant to hosts - and hosts are the
most important things in the Net.

I think this field has suffered considerable confusion due to your
architecture being named after "Locator / Identifier Separation" -
and due to continued claims that it really does support this Loc/ID
Separation naming model.

I suggest you rename your proposal. This would save a great deal of
confusion when people try to understand it.

Your architecture is completely different from the Locator /
Identifier Separation architectures such as HIP, GSE, ILNP,
Name-Based Sockets, RANGI and GLI-Split.  Your architecture is a
Core-Edge Separation architecture, which is a very good thing.

One of the most important benefits of your architecture (or any other
CES architecture) is that it does *not* involve hosts using "Locator
/ Identifier Separation".

  - Robin

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Mar 2010 14:08:17 -0800

Robin,

As I have said many times here on the list, what LISP
is calling "EID" is nothing more and nothing less than
an IP address. IP addresses are assigned to interfaces;
hence, they name an end system *interface* and not the
end system itself. Moreover, these LISP EIDs are routable
within a certain scope; even if that scope is only
node-local. Conversely, a true identifier (like a HIP
HIT) is not routable within any scope.

So, I have to agree that LISP is not really achieving
a true locator/identifier split. The LISP EID IMHO would
be more accurately renamed as "Endpoint Interface
iDentifeir", and the LISP acronym itself seems a bit
misleading.

Fred
[email-masked]

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robin Whittle
> Sent: Tuesday, March 09, 2010 7:21 PM
> To: RRG
> Cc: Scott Brim
> Subject: Re: [rrg] LISP does not implement Locator / Identity Separation
>

---

From: Robin Whittle <[email-masked]>
Date: Fri, 12 Mar 2010 12:27:16 +1100

Short version:    Fred agrees that LISP is "not really achieving
                  a true locator/identifier split.".  He also
                  thinks that "the LISP acronym itself seems a bit
                  misleading".  I think it is very misleading.

                  We discuss the meaning of "EID" and whether
                  such addresses - or any global unicast address -
                  identifies a host or just an interface on a host.

Hi Fred,

Thanks for your reply, in which you wrote:

> an IP address. 

Yes - all hosts and all routers except ITRs treat them the same as
any other global unicast IP address.  ITRs have a special algorithm
for handling packets whose destination address matches an EID prefix.

> IP addresses are assigned to interfaces; hence, they name an end
> system *interface* and not the end system itself.

A host may have multiple interfaces, but no two hosts share the same
interface.  So if a global unicast address IP address identifies an
interface, it is also true to say that as a result of this, this IP
address also identifies a host.  (This is not counting anycast, of
course.)

> Moreover, these LISP EIDs are routable within a certain scope; even
> if that scope is only node-local.

I am not quite sure what you mean by "node-local" in the context of
routing packets.

A packet whose destination address is a LISP EID is perfectly
routable anywhere in the world, assuming there are one or more Proxy
Tunnel routers advertising the "coarse" prefix which covers this EID
address.  (In Ivip, it is DITRs advertising Mapped Address Blocks -
MABs.)  All the routers except ITRs use the existing algorithm they
use for all other packets with global unicast destination addresses.
ITRs use a second algorithm.  For a full description, please see:

  Re: [rrg] LEIDs, SPI & ordinary IP addresses as both IDs & Locs
  http://www.ietf.org/mail-archive/web/rrg/current/msg06082.html

> Conversely, a true identifier  (like a HIP HIT) is not routable
> within any scope.

Yes, a HIP HIT is purely an Identifier.

> a true locator/identifier split. 

OK - thanks for this.

> The LISP EID IMHO would be more accurately renamed as "Endpoint
> Interface iDentifier", and the LISP acronym itself seems a bit
> misleading.  ["iDentifeir" typo corrected.]

Since a group of completely different architectures (Core-Edge
Elimination) do, as the central element of their architecture,
implement the "Locator / Identifier Separation" naming model (which
predates "LISP) I regard LISP's current name as being completely
misleading and a source of difficulty for anyone trying to understand
 the "LISP" architecture, or the entire scalable routing field.

To call what is currently known as a "LISP EID" address as:

   Endpoint Interface iDentifier

wouldn't make much sense to me, since this description also fits any
global unicast address which a host is using, or any other address
such as an RFC 1918 or RFC 4193 ULA address which also identifies a
host interface, and therefore also a host.

In Ivip, I chose the term "Scalable PI" (SPI) address for the new
"edge" subset of the global unicast address space which can scalably
provide provider-independent address space to end-user networks for
the purposes of portability, multihoming, inbound TE and mobility.  I
don't have a particular term for the remainder, which remains as
"core" space, according to the meaning of "Core-Edge Separation".

Since Ivip doesn't slice up SPI space into prefixes, there's no such
thing as an SPI prefix - other than a Mapped Address Block, which is
the DFZ-advertised prefix covering a block of SPI space.  I use a
term first used by Bill Herrin - "micronet" - to refer to the integer
number of contiguous IPv4 addresses or IPv6 /64s which all have the
same mapping.

I think the terms LISP, EID and RLOC are confusing.  "Proxy Tunnel
Router" is a poor term too, since it doesn't proxy for anything.

The term "LISP" (Locator Identity Separation Protocol) is really
muddying the waters and I think the field and the "LISP" architecture
would be much better off if it had a new name.

Perhaps I will refer to it as:

   "the architecture which, ideally, would be formerly known as LISP"

  - Robin

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Mar 2010 08:38:23 -0800

Robin,

> From: Robin Whittle [mailto:[email-masked]]
> Sent: Thursday, March 11, 2010 5:27 PM
> To: RRG
> Cc: Templin, Fred L

I will confess that I was just trying to make the best out
of a tenuous terminology when I came up with this expansion
for "EID". But, I think we are pretty far down the road with
EID/RLOC to consider abandoning them now.

Thanks - Fred