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:
http://www.ietf.org/mail-archive/web/rrg/current/msg06190.html
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
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
