Hi all, I’m quite confused by this request.
It seems like they either have an implementation issue (in Linux). I checked their documentation, which includes smoothing that looks a little like an Internet Draft: http://tipc.io/protocol.html <http://tipc.io/protocol.html> but it’s quite confusing. Taken at face value, they make their own argument that IP addresses won’t work - at which point running raw over IP serves no utility (sec 3.1.1), even though most of those claims are debatable (DNS-SD is too static? And expensive?? How so?). Then they reinvent the DNS in Section 6. Frankly, IMO this would probably have a difficult time arguing for a transport protocol port number, much less an IP protocol number. Joe > On Mar 17, 2020, at 3:34 PM, Suresh Krishnan <sur...@kaloom.com> wrote: > > Hi all, > IANA received an IP protocol number allocation request from Jon Maloy > <jma...@redhat.com <mailto:jma...@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 <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.dmit...@huawei.com > <mailto:kolmakov.dmit...@huawei.com>> > Ji Qin <jiqin...@huawei.com <mailto:jiqin...@huawei.com>> > Wei Yongjun <weiyongj...@huawei.com <mailto:weiyongj...@huawei.com>> > <songshuaishu...@huawei.com <mailto:songshuaishu...@huawei.com>> > Yue Haibing <yuehaib...@huawei.com <mailto:yuehaib...@huawei.com>> > Junwei Hu <hujunw...@huawei.com <mailto:hujunw...@huawei.com>> > Jie Liu <liujie...@huawei.com <mailto:liujie...@huawei.com>> > Qiang Ning <ningqia...@huawei.com <mailto:ningqia...@huawei.com>> > Zhiqiang Liu <liuzhiqian...@huawei.com <mailto:liuzhiqian...@huawei.com>> > Miaohe Lin <linmia...@huawei.com <mailto:linmia...@huawei.com>> > Wang Wang <wangwa...@huawei.com <mailto:wangwa...@huawei.com>> > Kang Zhou <zhouka...@huawei.com <mailto:zhouka...@huawei.com>> > Suanming Mou <mousuanm...@huawei.com <mailto:mousuanm...@huawei.com>> > > Hu Junwei is the one I see most active at the moment. > > Nokia: > Tommi Rantala <tommi.t.rant...@nokia.com <mailto:tommi.t.rant...@nokia.com>> > > Verizon: > Amar Nv <amar...@in..verizon.com <mailto:amar...@in.verizon.com>> > Jayaraj Wilson, <jayaraj.wil...@in.verizon.com > <mailto:jayaraj.wil...@in.verizon.com>> > > Hewlett Packard Enterprise: > <jonas.ar...@hpe.com <mailto:jonas.ar...@hpe.com>> > > WindRiver: > Ying Xue <ying....@windriver.com <mailto:ying....@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.jail...@wanadoo.fr > <mailto:christophe.jail...@wanadoo.fr>> > > Redhat: > The person contacting me to have TIPC integrated and maintained in RHEL-8.0 > was > Sirius Rayner-Karlsson <akarls...@redhat.com <mailto:akarls...@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 <https://new.abb.com/pl> > Mikolaj K. Chojnacki <mikolaj.k.chojna...@pl.abb.com> > Krzysztof Rybak <krzysztof.ry...@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.k...@gmail.com> (seems to be responsible for the > ZeroMQ port of TIPC) > John Hopkins University / Fast LTA, Munich <peter.hans.froehl...@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/ > <https://www.dektech.com.au/> > > Thanks > Suresh > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
