Short version: Toni's proposal seems to be a Locator/ID Separation
architecture (AKA Core Edge Elimination).
Hi Toni,
Thanks for your response. Unfortunately I can only get a vague idea
of what you are proposing from the text you wrote. It is quite a lot
of work to write up a new routing and addressing system in a manner
that other people can understand it clearly.
You wrote, in part:
> A look-up needs to be done once per stateful session. Thereafter
> nodes inform each other of any locator changes.
But what if both change their locators at the same time?
How can one node be sure a message supposedly from the other node,
regarding the other node's new locator, is authentic?
>> Then, for your concrete example, why do you argue that hosts
>> should do this extra work, rather than new elements in the
>> routing system such as ITRs, as in LISP, Ivip or (by some other
>> name) IRON?
>
> No extra work. Nodes will use locators for packet outreach and IDs
> for session maintenance.
There certainly is extra work. Initially the sending host A only
knows B's Identifier, and it somehow uses this with the number
servers to get a packet to B. I am not sure how A finds out B's
locator, but it needs to find this out ASAP so it can send subsequent
packets directly to B, without relying on any other servers.
There are extra delays in using these number servers.
When B gets a packet from A, it will have A's Identifier and it may
have A's Locator - but there's no way B can trust this Locator. So
it needs to do a lookup, or whatever it is you described with number
servers, to send a packet to A, rather than to some other host which
pretends to be A.
> The routing system will consist of path selection facilities that
> make use of locators. The node ID system will consist of ID
> distribution/matching servers.
I am sure you could write this up in a way others could understand,
but it will take a few pages and probably require some diagrams.
>> Does your concrete proposal involve new application protocols,
>> or can existing protocols work with IP addresses, with the stack
>> somehow implementing whatever is required so the application can
>> assume that an IP address is both an Identifier and Locator?
>
> For this separate uses of IDs and locators new application
> protocols or amendments of exiting ones are needed.
OK - so applications need to be rewritten and do more work. I think
there's no way anyone would be interested in adopting such a system,
since - as with other CEE architectures - the benefits for each
adoptor and for routing scalability only occur after almost everyone
has adopted it.
Requiring changes to host stacks is a real barrier to adoption.
Requiring applications to be rewritten is far worse. See:
http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/
>> This involves ensuring that a packet is never received by a host
>> which does not have the Identity implied by the application's
>> destination IP address.
>
> Yes, an important feature. Destination identifier.
It can only be achieved, as far as I know, by B doing a secure lookup
of A's Identifier to get A's Locator - and then sending the packet to
that Locator. (Or some alternative by which number servers send the
first packet and reliably and securely inform B what A's Locator is.)
>> Does your proposal provide a facility similar to today's anycast
>> and to round-robin DNS, where one DNS name resolves to multiple
>> IP addresses, meaning multiple hosts or sets of anycast hosts?
>
> Anycasting is a matter of naming and recognition of service types.
> It is not about naming nodes or their location. Service type
> naming is a different aspect of the architecture.
I am not sure what you mean by this, but it does not seem to accord
with my understanding of anycast being multiple hosts in multiple
locations all around the Net, with the same IP address. Then, the
interdomain routing system (without any extra elaboration for this
purpose) causes the packet to be sent to the "closest" such host.
("Closest" with BGP is not necessarily physically or topologically
close.)
> A node identifier may resolve to multiple locators, which would be
> used in a round-robin fashion or with some preference. But those
> locators would be each of the same node.
At present a FQDN can resolve to multiple IP addresses, each of which
combines the functions of Identifier and Locator for the particular
host in the round-robin group. Then the session begins and continues
with one of these hosts, and is maintained with this IP address.
With your proposal, an Identifier can have multiple locators, each
for a different node. But this seems to violate the concept of an
Identifier being specific to each physical node. Then, your
applications need to keep track of specific Identifier-Locator pairs,
since each pair with a different Locator refers to a different node -
and for session continuation, the session always needs to be with the
node specified by this pair.
You could do FQDN round-robin to Identifier, and then for each
Identifier, have a single node, with one or more Locators. That
would work fine, I think.
>> How would your proposal handle multihoming and mobility?
>
> Every "home" of a node may supply it with a locator. Locators may
> come and go. Sessions are maintained with identifiers.
Yes, but you have to organise a secure and efficient way to tell a
distant node B that A has now got a new Locator.
>> Is there any RRG proposed architecture which matches or
>> resembles your plan?
>
> Matching – no. Resembling – I guess no. Others are welcome to
> match.
Your proposal seems to be a host-based system along the lines of the
Core Edge Elimination architectures (the architectures which really
do implement Locator/Identifier Separation):
GLI-Split
ILNP - Identifier-Locator Network Protocol
Name-Based Sockets
RANGI
>> Also, how would your analysis of the goals and proposed
>> architectures differ from mine?:
>>
>> http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html
>
> I have not read all the writings there. Maybe in the course of
> this discussion I could answer. Or you could help me do so.
Other than Tony and Lixia's:
http://tools.ietf.org/html/draft-irtf-rrg-recommendation
my msg06219 is the only attempt anyone has made for writing what they
would like to see as an RRG Recommendation. Unlike Tony and Lixia's
document, my attempt covers mobility and includes a proper
description of goals and critiques of all proposals (or at least
descriptions of why they can't be considered proper proposals).
I understand that your plan would make life easy for the routing
system, compared to the additional mechanisms needed for LISP, Ivip
or IRON.
However, it is not clear to me why you want to place the extra
workload on nodes (AKA each communicating host), with the delays
required at each node which is part of a two-way communication, and
the need for complex security arrangements so each node can learn of
a new Locator for the other node ASAP.
It is not clear how you handle mobility, since that would require all
communicating nodes of a mobile node to instantly know its new
Locator, the moment it acquires a Locator in a new network. This can
happen in a split second, when one radio network goes down and
another is chosen - or even on the same radio network when the node
communicates with a new radio tower (even if the node hasn't moved -
the network can make this happen) which uses a different base-station
controller which uses a different IP gateway. For instance, I
understand that in Beijing, in one 3G network, there are multiple IP
gateways in the whole city. Your node can discover its new Locator
quickly, but how can it securely communicate this to all its
correspondent nodes in time not to lose any packets from them? If
there are 50 correspondent nodes, then that is 50 secure messages
which need to be sent out and acknowledged. That is a lot of work
for a 3G handset, and it would chew up expensive radio bandwidth.
Also, what if both nodes in a communication get new Locators at the
same time? There's no way either can know the new locator of the
other, since it can't receive the update message, which would be sent
to its old Locator.
These last two paragraphs are critiques which apply to the other CEE
architectures too.
If you write up your proposal in sufficient detail and read the other
CEE architectures, I think you may find some points of commonality.
Whatever it is you are proposing, it is a Loc/ID Separation (CEE)
architecture - and I oppose such architectures for the reasons
mentioned in my msg06219 and in my recent message:
http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
