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

Suresh Krishnan <Suresh@kaloom.com> Tue, 17 March 2020 22:34 UTC

Return-Path: <Suresh@kaloom.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 D11853A0922 for <int-area@ietfa.amsl.com>; Tue, 17 Mar 2020 15:34:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=kaloom.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 xtO-EPBeR4Rr for <int-area@ietfa.amsl.com>; Tue, 17 Mar 2020 15:34:28 -0700 (PDT)
Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670098.outbound.protection.outlook.com [40.107.67.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5ED3A0921 for <int-area@ietf.org>; Tue, 17 Mar 2020 15:34:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c5hOCOrJrkskVtCjrbn3H6woLlGPjTx4z5MM0ofAyOCJfDmcBnmEuul5oY/TrHGffH/jK9A5GS/kyDs/jH0VUN4dEoxwsXSoPpe7vbm7d43dABUF45n1OJu8nFnixdfLh1+/cQCCppMc6zKgs5qph7ov95/gH/gGqd0ft/LJqmXD7FI82+PqpmdxuIiYmMtxISBSvvqx1ckMLaaqZeX7/tt/yxH5dtL0DWqYeenbSEtj//RQiq8fYxkrGYnFHmpBzXv4mc0Lp2oCPopfIZVCduAQLZDtSViHt7DIlkN0NW2NhOtSR3gzeffsqCqwA3nOWT77Ul+ApLjO7j1vVKYk4w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=YPEfcMguOpzeLFysfw6UATl1Ecvr6Ybot0oJk2rdjjU=; b=aLDIxpXYXURte/HISQir2tYr3KlA4hp8iKIFIOpXbkuxvMpOOGlzMg2SlWvD6K487fVRBVrDiCBSKSr339WLToHJowuGrofVGLNVbPrqepXf36CbwjGsFXOB/n5g+h6IOHWaz+aHCr+vOQsCcpGZZbyApEfyW7RDjGeqxEPVfKrzfTEkENCMjx2q0tQoxiNUjDKpMNc6+j7aJzBnHUag8pKTEQzUXN2cXwIw/veTwn0ftH9433lDP+JD4qhXlQl9cA2VurPeynS/TnOu3bVGlG81Vz+r6kZO7XUL1caCjNkcGfe2fUgcFCWo28eKiSRunvFy8imPigOL1rFu00osaQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kaloom.com; dmarc=pass action=none header.from=kaloom.com; dkim=pass header.d=kaloom.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=YPEfcMguOpzeLFysfw6UATl1Ecvr6Ybot0oJk2rdjjU=; b=XWHcBa39WtFCmYQFiD9a3sYe2MiLaNJcEFD33fGRt0UEH90wjwu1qgjDcpnpX5nQw7ECMfl7Z0dAGNRTonjzjUnQabAG4I36RuQw9clPNJWwwinRNziWpqb7IWdOrhSs1aRchD3Ntdi7kkk36DB9ioeL/4WQOfa3LZiV3iDeYv4=
Received: from QB1PR01MB3219.CANPRD01.PROD.OUTLOOK.COM (52.132.84.225) by QB1PR01MB2324.CANPRD01.PROD.OUTLOOK.COM (52.132.85.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Tue, 17 Mar 2020 22:34:26 +0000
Received: from QB1PR01MB3219.CANPRD01.PROD.OUTLOOK.COM ([fe80::7161:57df:544c:53d9]) by QB1PR01MB3219.CANPRD01.PROD.OUTLOOK.COM ([fe80::7161:57df:544c:53d9%3]) with mapi id 15.20.2814.021; Tue, 17 Mar 2020 22:34:26 +0000
From: Suresh Krishnan <Suresh@kaloom.com>
To: int-area <int-area@ietf.org>
Thread-Topic: IP Protocol number allocation request for Transparent Inter Process Communication (TIPC) protocol
Thread-Index: AQHV/Kw2xzCg26p1OES6RIIP+Za7lg==
Date: Tue, 17 Mar 2020 22:34:26 +0000
Message-ID: <DC440B28-DA08-499F-8A2A-7A8ACF880724@kaloom.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com;
x-originating-ip: [45.19.110.76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1a8ffb20-eea8-4370-96cf-08d7cac35971
x-ms-traffictypediagnostic: QB1PR01MB2324:
x-microsoft-antispam-prvs: <QB1PR01MB23241F9E17BC6FCB5603F248B4F60@QB1PR01MB2324.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0345CFD558
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(376002)(136003)(396003)(346002)(366004)(199004)(71200400001)(64756008)(66446008)(316002)(36756003)(2616005)(966005)(91956017)(6916009)(66476007)(66946007)(6512007)(66556008)(76116006)(6486002)(508600001)(33656002)(66574012)(8936002)(6506007)(81156014)(81166006)(8676002)(186003)(5660300002)(2906002)(26005)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:QB1PR01MB2324; H:QB1PR01MB3219.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +WbmoxyYp27c0f9gWJC/dReG74zk/DTKClqyqMZ6dawIrKO9s13orTXobjDelgG7oCI9QnW59V+tGrA0IbRskAyqALtn6aBHfnfYApSKZM3rPCpkV3qKqLIM7wTHp3SPVMu3I7osVE57g8Py12fyuept1R+V9+MUHrZppcro6aU3AGtjpVYMUDQuTbwXAdo65jBx702dLR2qiY9KFDH9UE3ZdrOEfreQRVh/bbYvT7gttgTJKe6G/XmEGnU2Wea4FDaxWvtHMrZOKr9SlHbUtS3fteFzNFqzIN1Gu4Nz7wFEFtG6XPEFnlcXaG8AtqidLHZh58XIJYZeiIYiyRLb4D2afewvYHqtFaArbuo/WB1rr0gifej3m2EzkHxQsS6CWxyd/Uw1ZihH/1iOk9VQSu9cEjIHQMBftvfawIqrzRacmljksgjFWrEhvi0JJo9uvoqrkRUj+APtZigXAWtyV43gIhPuDNIGBMKpzipLq8ZqU8rIZktpCOLgazGaHND2O+QMJceq3AwF5zmXFGVd2w==
x-ms-exchange-antispam-messagedata: x+Pszub9lDdkN+Yl6WUmlcZLQmc2zn50OL3XHCMlHyg8h4Lzuupg1U9/geayITmLHTm0nucMUfemxpmOn3rN+Yd3SNtWx2nQicaKNsAEKWax/LC2bFVYLqUIuvGTZA/octmtEIO01IDz09ZaSG3Qkw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DC440B28DA08499F8A2A7A8ACF880724kaloomcom_"
MIME-Version: 1.0
X-OriginatorOrg: kaloom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a8ffb20-eea8-4370-96cf-08d7cac35971
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 22:34:26.3195 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dPdwdQw4q/JAc6yGqnfsE0DiVn1r5YybrKYAx45oX2ZfHfYS9GcZfRYkdKUKKbQ6UOpzxaNvc5xA086tugcbiA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB2324
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/vujFMgiVtATYzvWxQ7Wykdp4flI>
Subject: [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: Tue, 17 Mar 2020 22:34:31 -0000

Hi all,
  IANA received an IP protocol number allocation request from Jon Maloy <jmaloy@redhat.com<mailto:jmaloy@redhat.com>> for the Transparent Inter Process Communication (TIPC) protocol. I picked up this request as Internet AD as the registration procedure requires IESG Approval. I had provided the information below to the IESG and discussed this with a favorable view of this request. I am recommending allocation of an IP protocol number for this. If you have any concerns that you think I might have overlooked, please let me know by end of day March 24 2020.

After several round trips of back and forth probing I had collected the following information regarding the protocol number request for TIPC. There were two main questions I had for him:

* Q1: Why did they want an IP protocol number?
* Q2: Is the protocol implemented and deployed widely?

Q1: Why did they want an IP protocol number?
====================================

There are two main reasons why they want to reserve an IP protocol number:

1)  Performance
They are currently working on adding GSO support to TIPC, including a TSO-like "full-size buffer pass-thru" though virtio and the host OS tap interface. They have experimentally implemented GSO across UDP tunnels, but performance is not good because of the way the tunnel GSO is implemented, and there is no 'pass-thru' support for this in Linux. They have even done the same at the pure L2 level, but L2 transport is sometimes not accepted by the cloud maintainers or the telco operators, and hence they need an alternative. The best alternative, both from a performance and acceptability viewpoint would be to establish TIPC as a full-fledged IP protocol, apart from the traditional L2 bearer many users are still using.

2) Currently TIPC has two user address types:

struct tipc_service_addr{
    uint32_t type;
    uint32_t instance;
    uint32_t node;
};
struct tipc_service_addr{
    uint32_t port;
    uint32_t node;
};

They want to complement this  with a new API where we have a unified address type:
struct tipc_addr{
   u8 type[16];
   u8 instance[16];
   u8 node[16];
};

This would give a 128-bit value range for both 'type', 'instance' and 'node', and opens up for new opportunities:
- Users will never need to coordinate 'type' values since there will no risk of collisions.
- Users can put whatever they want into the fields, e.g., an IPv6 address, a Kubernetes or Docker container id, a LUKS disk UUID or just a plain string.
For the 'node' id this has already been implemented and released, but it is not reflected in the API yet.

For the API extension they need a new IPPROTO_TIPC socket type which can be registered and instantiated independently from the traditional AF_TIPC socket type.

You can find more info about this at http://tipc.io

Q2: Is the protocol implemented and deployed widely?
==========================================

The requester provided the following information when I asked about who was currently using TIPC (pretty much about adoption and deployment):

I can give you a list of current or recently active code contributors and companies/people who have been asking for support:

Huawei:
For natural reasons I don't know any details about them, I can only name persons I have seen contributing to netdev or being active on our mailing lists. Huawei people sometimes use gmail addresses when posting questions and patches, so there are more persons than I have listed here.
Dmitry Kolmakov <kolmakov.dmitriy@huawei.com<mailto:kolmakov.dmitriy@huawei.com>>
Ji Qin <jiqin.ji@huawei.com<mailto:jiqin.ji@huawei.com>>
Wei Yongjun <weiyongjun1@huawei.com<mailto:weiyongjun1@huawei.com>>
<songshuaishuai2@huawei.com<mailto:songshuaishuai2@huawei.com>>
Yue Haibing <yuehaibing@huawei.com<mailto:yuehaibing@huawei.com>>
Junwei Hu <hujunwei4@huawei.com<mailto:hujunwei4@huawei.com>>
Jie Liu <liujie165@huawei.com<mailto:liujie165@huawei.com>>
Qiang Ning <ningqiang1@huawei.com<mailto:ningqiang1@huawei.com>>
Zhiqiang Liu <liuzhiqiang26@huawei.com<mailto:liuzhiqiang26@huawei.com>>
Miaohe Lin <linmiaohe@huawei.com<mailto:linmiaohe@huawei.com>>
Wang Wang <wangwang2@huawei.com<mailto:wangwang2@huawei.com>>
Kang Zhou <zhoukang7@huawei.com<mailto:zhoukang7@huawei.com>>
Suanming Mou <mousuanming@huawei.com<mailto:mousuanming@huawei.com>>

Hu Junwei is the one I see most active at the moment.

Nokia:
Tommi Rantala <tommi.t.rantala@nokia.com<mailto:tommi.t.rantala@nokia.com>>

Verizon:
Amar Nv <amar.nv@in.verizon.com<mailto:amar.nv@in.verizon.com>>
Jayaraj Wilson, <jayaraj.wilson@in.verizon.com<mailto:jayaraj.wilson@in.verizon.com>>

Hewlett Packard Enterprise:
<jonas.arndt@hpe.com<mailto:jonas.arndt@hpe.com>>

WindRiver:
Ying Xue <ying.xue@windriver.com<mailto:ying.xue@windriver.com>>
He is my co-maintainer at netdev ans sourcefoge.
Windriver has several products in the field based on TIPC, e.g. control system for Sikorsky helicopters.

Orange:
Christophe JAILLET <christophe.jaillet@wanadoo.fr<mailto:christophe.jaillet@wanadoo.fr>>

Redhat:
The person contacting me to have TIPC integrated and maintained in RHEL-8.0 was
Sirius Rayner-Karlsson <akarlsson@redhat.com<mailto:akarlsson@redhat.com>>
He motivated it with a request from "a telco vendor", but I don't know which one.
Hence, TIPC is now integrated in and officially supported from RHEL 8.1

ABB:
https://new.abb.com/pl
Mikolaj K. Chojnacki <mikolaj.k.chojnacki@pl.abb.com>
Krzysztof Rybak <krzysztof.rybak@pl.abb.com>

Ericsson:
All (dozens of) applications based on the TSP and Core Middleware/Components Based Architecture (CMW/CBA) platforms is per definition based on TIPC. They have not yet started to use TIPC on their Kubernetes based ADP platform, but there is work ongoing on this.

I also see numerous other people being active, from small (I believe) companies, universities and private contributors. E.g.,
Innovsys Inc  http://www.innovsys.com/innovsys/
Allied Telesis https://www.alliedtelesis.com/
Telaverge Communications http://www.telaverge.com/
Ivan Serdyuk <local.tourist.kiev@gmail.com> (seems to be responsible for the ZeroMQ port of TIPC)
John Hopkins University / Fast LTA, Munich <peter.hans.froehlich@gmail.com>
Just to mention a few...

TIPC is currently maintained jointly by Ericsson, WindRiver, Redhat, and the Australian consulting company DEK Technologies https://www.dektech.com.au/

Thanks
Suresh