Re: [Int-area] IP Protocol number allocation request for Transparent Inter Process Communication (TIPC) protocol

Jon Maloy <jmaloy@redhat.com> Fri, 20 March 2020 14:09 UTC

Return-Path: <jmaloy@redhat.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0763A0A08 for <int-area@ietfa.amsl.com>; Fri, 20 Mar 2020 07:09:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mpe7kcR1SssQ for <int-area@ietfa.amsl.com>; Fri, 20 Mar 2020 07:09:24 -0700 (PDT)
Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [63.128.21.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB463A09F1 for <int-area@ietf.org>; Fri, 20 Mar 2020 07:09:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1584713363; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=M4r4TxiObhpwZvfF85cXdgf9QeKN/6J1h9qaxnt0ElA=; b=cdmMcZoxC1NDM8XU5oKnIv6LLgIgxBrU7xiPwVGnmZ8R6g4/wAGxddVaDxmrbAvt9pUtMh amdR5S6s398cl3F/EiiNP4quaVQlXUNtlFd+8UIR8juqh0qlibmvr876GJRlGApFgbOJVw aDXl4/+QM46T1hxxKPWpDIat4mYjTs8=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-266-cHios4lZOZu5nw_85oUsNQ-1; Fri, 20 Mar 2020 10:09:18 -0400
X-MC-Unique: cHios4lZOZu5nw_85oUsNQ-1
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BA09F107ACCA; Fri, 20 Mar 2020 14:09:17 +0000 (UTC)
Received: from [10.10.112.60] (ovpn-112-60.rdu2.redhat.com [10.10.112.60]) by smtp.corp.redhat.com (Postfix) with ESMTP id D789319757; Fri, 20 Mar 2020 14:09:16 +0000 (UTC)
To: Joseph Touch <touch@strayalpha.com>
References: <DC440B28-DA08-499F-8A2A-7A8ACF880724@kaloom.com> <A6B82786-FB50-4AAA-8D69-0A55FEB5DC3B@strayalpha.com> <4bad2d30-0220-a836-451d-b01fdba4d098@redhat.com> <0C774D74-89A9-44CB-BCE7-A0ACC138C10F@strayalpha.com> <4cd43b9b-f7fa-0fc5-3ba9-11a735268288@redhat.com> <BAAD573B-497C-4F86-AF7A-776781698717@strayalpha.com>
Cc: int-area <int-area@ietf.org>, Suresh Krishnan <suresh@kaloom.com>
From: Jon Maloy <jmaloy@redhat.com>
Message-ID: <eb054946-0bbe-ce6b-3a7d-6e2630ae4c6f@redhat.com>
Date: Fri, 20 Mar 2020 10:09:15 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <BAAD573B-497C-4F86-AF7A-776781698717@strayalpha.com>
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: multipart/alternative; boundary="------------930BD39C524C28370559C65C"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/kFnJ6R5TNX6jrvtTIOb3HdsO5Rg>
Subject: Re: [Int-area] IP Protocol number allocation request for Transparent Inter Process Communication (TIPC) protocol
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2020 14:09:34 -0000

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 <jmaloy@redhat.com 
>> <mailto:jmaloy@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