Short version: CEE would change the current naming model to a
"Locator / Identifier Separation" model. This would
leave the routing system unaltered, but would be the
biggest change ever made to architecture of IPv4 or
IPv6.
The "Locator / Identifier Separation" model is
widely by RRG folks as being desirable or essential.
I argue it is undesirable and must be avoided -
because adopting it would mean that most
communication sessions would take longer to
establish and involve more data being sent, more
packets being sent, more work and state for hosts
more delays due to global lookups and/or lost
packets etc. This would be much worse than the
long-path problem and other causes of "initial
packet delay/loss" in LISP-ALT.
Hi Javier,
You wrote:
>> However, I think such problem such as you suggested exists with Name
>> Based Sockets. I haven't yet recieved clarification from Christian,
>> but see my concerns about his model:
>>
>> Role Level Name Based Sockets?
>>
>> Text name <---] FQDN
>> Identifier <---]
>> Locator <---- IPv6 address
> As per my understanding
>
> Role Level
>
> Text name <---] FQDN
> Identifier <---] FQDN (used as a nonsensical text string)
> Locator <---- whatever address
>
> There are no DNS queries done after the initial connection.
This is only true if the second host, which you refer to as the
"server", doesn't care whether the packet it sends goes to the host
with the Identifier which was in the first packet, or to some other host.
Just having a packet arrive with a particular Identifier and Locator
doesn't establish reliably that the host with this Identifier can be
reached with that Locator. With some servers, such as DNS, which
don't care about the identity of the hosts they send their replies
to, what you say is true.
For many other applications, it is important that the respondent know
for sure that the packet it sends won't go to any other host than the
one with the same Identity as that contained in the packet it received.
This is easy with today's naming structure, where the IP address
functions as both Identifier and Locator. The respondent gets a
packet with source address XYZ and can simply reply with a packet
addressed to XYZ. (In neither naming model can the respondent know
for sure that the initial packet was sent by the host with the
Identifier and Locator indicated by the source field(s) of that
packet, but that is a separate issue.)
With today's naming model, the packet won't necessarily get to the
host whose Identity is XYZ, because it may be lost. However, the
routing system ensures that the packet won't go to a host which does
not have Identity XYZ. (In both models, a physical host may have
multiple Identities too - multiple IP addresses in the current model
or multiple Identifiers in the CEE Loc/ID Sep. model.)
With CEE architectures, at this early stage in the communication
process, the respondent host can only ensure its reply packet does
not go to a host which does not have the Identifier contained in the
initial packet by the the respondent doing an Identifier ->
Locator(s) lookup. At this point in the communication, the lookup is
the only way of knowing which Locators the host with a given Identity
has. (Later, if the hosts establish nonces or some other
authentication mechanism, then one host, already known to be the one
with a given Identity, can securely tell the other that it has a new
Locator and so the other host should use that Locator for future
packets.)
CEE completely alters the naming model from the current one in which
Identifier and Locator roles are both played by the one IP address,
to one of several models in which these roles are played by different
objects in different namespaces.
This is widely regarded in the RRG as a good thing. Tony regards it
as "doing it right". I believe that this approach will slow down
most communication establishment and that we should retain the
current naming model.
CES architectures retain the current model. CEE architectures change
it to the "Locator / Identifier Separation" model, which is what I am
arguing against. This model will forever burden hosts with extra
work, involve extra traffic, extra packets and longer delays and
greater sensitivity to packet loss.
Please see:
Today's "IP addr. = ID = Loc" naming model should be retained
http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html
I hope you will write about why you agree or disagree with this.
> What happens on the client side is:
> 1. Query DNS with the FQDN
> 2. Get an IP
> 3. Send packets to that IP and add your Text name (=FQDN)
>
> and on the server side:
> 1. Get a packet with the NBS name extension
> 2. Add text name (=FQDN) to reply packets
>
> So, the DNS is only used in the initiating packet, to pull out a
> reachable locator, the rest is then done without interaction with DNS.
Yes, but only if the "server" doesn't care whether its reply goes to
the host with the Identifier which is in the query packet. In NBS,
this is a FQDN. In most or all other CEE architectures, the
Identifier is a separate thing from the FQDN.
> The current track for NBS is going for a shim6 like approach for
> management of the locators (for multi-homing and mobility).
>
> Primary IP : A text-string (FQDN)
> Active IP : Whichever locator is chosen and verified as reachable
> (REAP?)
> Locator pool: Set of locators.
I don't clearly understand the above. I hope Christian will soon
join this discussion.
- Robin
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
