Short version: Toni asked if I support the routing system
addressing nodes (complete hosts, via any of their
one or more interfaces) rather than the current
arrangement of each IP address referring to a
particular interface.
I answer in the context of retaining the existing
overloading of "Identifier" and "Locator" functions
on an IP address, which I support the continuation
of. My answer is that I support the continuation of
the existing practice of these things referring to
interfaces, rather than nodes.
I did not attempt to discuss this in terms of Toni's
preferred architecture: Locator / Identifier
Separation. However, ILNP does implement what he
wants, and I think the other CES architectures -
at least Name Based Sockets and RANGI - do.
Hi Toni,
On (2010-09-24 msg07379) you wrote, initially quoting
draft-rja-ilnp-intro-06:
> ILNP: The Routing RG has had remarkably little consensus on
> anything, so virtually all Routing RG outputs are
> considered controversial.
>
> I was surprised to know that Robin is against location/identity
> separation. Are you not, Robin?
>
> Distinction between a node's identity and topological location is
> natural, because the same node can be attached to the general
> network at different points. So, to name the node independently
> of its point of attachment, we need an identifier assigned to the
> node. And we also need a locator to represent the node's
> topological position.
>
> Do you consent?
Then you quoted my reply (2010-09-21 msg07358 "Re: Consensus on
identity/location separation - Objections to Loc/ID Sep AKA CEE") to
your message that day (msg07356 "Consensus on identity/location
separation")
>> Short version: Why I think CEE (Locator / Identifier Separation)
>> is inferior in general to CES - and in particular
>> why CEE cannot provide mobility in an acceptable
>> manner, while CES with TTR Mobility can.
>>
>> CES continues the current pattern of the routing
>> system providing significant services to the hosts.
>>
>> CEE requires the routing system to do less work,
>> and hosts to do more, including sending and
>> receiving more packets, holding more state,
>> running more complex software - and suffering
>> more delays and sensitivity to packet loss.
>> This is unacceptable in general, and is
>> particularly unacceptable for battery powered
>> hosts hanging on via slow and potentially
>> unreliable 3G etc. radio links.
Then you wrote:
> OK. Half of us (who expressed opinion) are for, the other half are against
> location/identity separation.
Only you and I participated in the discussion.
You supported introducing Locator / Identifier Separation and I argued
against it - for retaining the current "overloaded" arrangements and
for introducing a CES architecture (Ivip, LISP or IRON) which would
continue to support these arrangements.
Then you asked another question:
> Now node reference.
>
> Endpoints of data communication in the general network are
> computers, i.e., nodes. Naming nodes is especially appropriate
> for path selection among nodes. It is the node that communicates
> with another node, so their location/identity needs to be
> expressed to the routing system.
> In today's Internet naming endpoints is actually of their
> interfaces to links. This leads to weird situations where
> communication with a correspondent at a remote part of the
> 'Net is conducted on a per interface basis; and a change in
> the local interfaces of communication (i.e., links of
> attachment) means to the remote party a connection with
> different entity. (identity again) In path selection, naming
> interfaces designates the norm that a route in one direction
> is totally different from the same route in the reverse
> direction, instead of being seen as a reverse path.
OK.
> So, do you consent that nodes (instead of interfaces) have to be
> referenced with locators(addresses)/identifiers?
I am only discussing this in the context of retaining the current
overloading of identifier and locator functions onto the IP address -
that is, the current Internet protocols. This would be retained by
the CES architectures. I won't discuss what I think would be best for
what you prefer - Locator/Identifier Separation (CEE architectures) -
since I don't support such an architecture.
I don't nodes "have to be" referenced by rather than the specific
interfaces of a node, since the Internet today works with the
"IP-address = identity = routing locator" applying to a specific
interface, such as an Ethernet NIC or wireless interface, rather than
the "IP-address = identity = routing locator" applying to a particular
computer (i.e. "node" AKA host).
However, what you suggest can be done for applications which want to
do it, using existing protocols:
1 - Application always references a remote node via its FQDN.
2 - Lookup of the FQDN returns (round-robin result of multiple
IP addresses in no particular order) the IP addresses of the
one, two or more interfaces of a single physical node.
3 - Application sets up sessions to each such interface (from its
one or more interfaces) and uses them in some way for load
sharing, other kinds of traffic engineering and most
importantly for recovery from failure of one interface (or that
interface becoming unreachable) with session survival - AKA
"multihoming".
To be able to add interfaces during the session would require
extra protocols between the hosts, with requisite authentication
guff, or the originating host periodically performing another
DNS lookup of the FQDN in order to get the latest set of IP
addresses.
This won't provide mobility in any usable form.
This chews a global unicast IP address for each interface, but
applications can be written to do this today. I can't think of any
which do, but that doesn't mean it isn't, can't or shouldn't be done.
I do not support the change you are suggesting, which I understand
involves changing the Internet protocols to coerce all nodes to
communicate only in terms of themselves, irrespective of what
interfaces they are using.
One reason is that a node might not want incoming traffic to arrive on
all its interfaces. Another is that it might not want to send traffic
on all its interfaces.
Some interfaces may be slow, expensive or unreliable - or the node may
want to avoid using them so they are ready to accept some other stream
of packets.
Some interfaces might, for policy reasons, be unsuitable for
particular types of communication. Some interfaces might use networks
with too high a latency, or too high a packet loss, or too small an MTU.
So, to make your idea workable, I think a given physical computer
would need to generate multiple Identities, with each such Identity
assigned a set of its Interfaces suitable for particular kinds of
communication.
This can already be done by any application which is suitably written,
as I just described.
I think your intention is to support multihoming, traffic engineering
and probably mobility on a host-by-host basis - as is the case for
instance with ILNP. However, I think it is best to have the
multihoming done at the level of the border routers of an end-user
network, without bothering each host at all with anything to do with
multihoming. CES architectures do this. CEE architectures make each
host responsible for handling multihoming, TE and mobility - which I
think is the wrong division of labor and would be very hard to manage,
test and make robust compared to doing everything at the level of the
end-user network as a whole.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
