Adding cc to int-area@ietf.org, since I forgot that in my original response..
On 3/19/20 9:18 PM, Joseph Touch wrote:
On Mar 19, 2020, at 4:46 PM, Jon Maloy <jma...@redhat.com
<mailto:jma...@redhat.com>> wrote:
IP addresses are no good in the *user API*, because they are
location bound.
That is also why DNS was invented, I believe.
DNS names are intended to be a human-rememberable alias to an IP
address. They do not indicate a location any more than an IP address
does or does not.
Exactly. Read what I wrote again.
IP addresses are no good in the USER API because they are location bound.
False. DNS names are provided as an alternative for the user API
because they are easier for people to remember and type.
Then I should probably rephrase this so saying that "IP addresses AND
DNS names and are no good in the user API...", although I don't quite
agree with that. DNS names are of course much more convenient for a user
to deal with than IP addresses.
DNS names are no more or less location-independent than IP addresses.
This is also why DNS was invented...
False. The reason the DNS exists has nothing to do with location. It’s
simply string substitution for convenience, or at least was ONLY that
originally.
I think you just supported my case for a location independent addressing
scheme. This was one of the original motivations for developing TIPC in
the first place. A programmer using TIPC can hard code his service
addresses if he wants to, ignoring the number of or location of the
corresponding endpoints, even as those move around or scale up/down
quite fast.
I don't know how much you have studied the rest of the tipc.io web site,
but you should be aware that there are significant differences between
what is described in the protocol description and what is current reality:
1) There is no zone/cluster/node hierarchy any more. A TIPC network
consists of a cluster of more or less (normally full-mesh, but that is
not a requirement) interconnected nodes. That is all.
2) Nodes are currently identified by a flat, unstructured 128-bit
identifier field, which may or may not be based on a MAC address, an
IPv6/v4 address, a string (e.g., host name) , a UUID, or something else.
3) Clusters may scale up to 1000 fully-meshed nodes, still with
second-speed peer failure discovery. This is thanks to the
patent-pending hierarchical neighbor monitoring algorithm.
4) We have added the concept of "communication groups" (also
patent-pending), which caters for high-speed, loss free, flow controlled
unicast, anycast, multicast and broadcast inside very large groups of
sockets. All of those using the location independent addressing scheme
we provide in TIPC, of course. To achieve anything like that using DNS
is very hard to imagine for me.
5) And much more.
In short, an Informational RFC for TIPC would be a significant upgrade
from the draft version I handed over to Suresh yesterday. That one is
the base for the current protocol description at our web page, which
hence also needs an update.
Regards
///jon
Joe
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
