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 <[email protected]> wrote: > > Hi all, > IANA received an IP protocol number allocation request from Jon Maloy > <[email protected] <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> > Ji Qin <[email protected] <mailto:[email protected]>> > Wei Yongjun <[email protected] <mailto:[email protected]>> > <[email protected] <mailto:[email protected]>> > Yue Haibing <[email protected] <mailto:[email protected]>> > Junwei Hu <[email protected] <mailto:[email protected]>> > Jie Liu <[email protected] <mailto:[email protected]>> > Qiang Ning <[email protected] <mailto:[email protected]>> > Zhiqiang Liu <[email protected] <mailto:[email protected]>> > Miaohe Lin <[email protected] <mailto:[email protected]>> > Wang Wang <[email protected] <mailto:[email protected]>> > Kang Zhou <[email protected] <mailto:[email protected]>> > Suanming Mou <[email protected] <mailto:[email protected]>> > > Hu Junwei is the one I see most active at the moment. > > Nokia: > Tommi Rantala <[email protected] <mailto:[email protected]>> > > Verizon: > Amar Nv <[email protected] <mailto:[email protected]>> > Jayaraj Wilson, <[email protected] > <mailto:[email protected]>> > > Hewlett Packard Enterprise: > <[email protected] <mailto:[email protected]>> > > WindRiver: > Ying Xue <[email protected] <mailto:[email protected]>> > 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 <[email protected] > <mailto:[email protected]>> > > Redhat: > The person contacting me to have TIPC integrated and maintained in RHEL-8.0 > was > Sirius Rayner-Karlsson <[email protected] <mailto:[email protected]>> > 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 <[email protected]> > Krzysztof Rybak <[email protected]> > > 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 <[email protected]> (seems to be responsible for the > ZeroMQ port of TIPC) > John Hopkins University / Fast LTA, Munich <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
