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,

Thanks for your reply, in which you wrote:

>>                  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.
> 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.

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:

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

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

> 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.

"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

rrg mailing list

Reply via email to