HotRFC @ IETF-105, Montreal Sunday, July 21, 2019, 1800-2000 Info: https://www.ietf.org/how/meetings/105/hotrfc/ Materials: https://datatracker.ietf.org/meeting/105/session/hotrfc ===================================================================== 1. Service Oriented IP Brian E Carpenter Service Oriented Internet Protocol (SOIP) proposes a new, backwards-compatible, approach to packet forwarding, where the service required rather than the IP address required acts as the vector for routing packets at the edge of the network. There's a draft (draft-jiang-service-oriented-ip) and there's even some toy code, at https://github.com/becarpenter/tlv. ===================================================================== 2. Asymmetric IPv6 Brian E Carpenter Asymmetric IPv6 is a new approach to IPv6 header compression for use in IoT scenarios where minimizing packet size is crucial but routing performance must be maximized. There's a draft (draft-jiang-asymmetric-ipv6). The idea is to make packets shorter without needing a decompression step. ===================================================================== 3. iCAN Do It Liubing (Leo) iCAN (instant Congestion Assessment Network) is a mechanism running directly on network nodes: o To adjust the flows paths based on real-time measurement of the candidate paths. o The measurement is to reflect the congestion situation of each path, so that the ingress nodes could decide which flows need to be switched from a path to another. This is something that current SDN and TE technologies can hardly achieve: o Controller is slow and far from the data plane, it is neither able to assess the real-time congestion situation of each path, nor able to assure the data plane always go as expected (especially in SRv6 scenarios). However, iCAN can work with SDN perfectly: controller planning multi-path transmission, and iCAN does the flow optimization automatically. o Traditional TE is not able to adjust the flow paths in real-time. Aim: call for attention and partners Relevance to IETF: This work might be related to TEAS/SPRING/IPPM WGs. ===================================================================== 4. Trustworthy Multipurpose RemoteID (TM-RID) Bob Moskowitz Stuart Card To mitigate the risks presented by Unmanned Aircraft Systems (UAS), the US FAA and other government agencies internationally soon will require, and various bodies are drafting standards for, remote identification. ASTM's proposed Broadcast Remote ID specifies how Unmanned Aircraft (UA) within Line Of Sight (LOS) of an observer can use a one-way RF broadcast to identify themselves and provide other latency-sensitive safety-critical information. ASTM's proposed Network Remote ID specifies how this same information can be obtained, starting from an observed UA's location, via the Internet. All such proposals hinge on a unique ID for each UA, a method whereby this ID (along with operator contact information etc.) can be registered, and a method by which a subsequent ID assertion can be authenticated by authorized parties. Network RemoteID uses the Internet to map current aircraft locations to identities. To avoid being deceived by malicious spoofing of these critical mappings, we need strong authentication. To maintain privacy (from unauthorized eavesdroppers, not from legitimate authorities), we need strong encryption. HIP provides both of these. Thus, we propose to consolidate the 4-tuple of (UA ID, UA physical location, UA onboard host ID, UA onboard host logical location [IP address list]) to a 3-tuple by standardizing the HIP Host Identity Tag (HIT) as a 4th RemoteID type. Depending upon the level of adoption by a given UAS operator, this can provide 3 levels of benefit: 1. Use of the Internet Domain Name System (DNS, the world’s largest distributed database, with well-established update procedures) as a RemoteID registry 2. Strong authentication of not only Network RemoteID but also Broadcast RemoteID messages 3. Rapid establishment of authenticated and encrypted communications with any observed UA that is suitably equipped. We call this “Trustworthy Multipurpose RemoteID (TM-RID)” and have begun preparations for prototyping and experimentation at the New York UAS Test Site. A sidebof will be held Monday at 6pm in room C2. ===================================================================== 5. Mobility Networking Sharon Barkai Would like to introduce a new draft-rfc we have been working on in the area of mobility, v2v, v2x, networking within the LISP working group. LISP is a set of RFCs dealing with virtual IP and map-assisted-ip-overlays. Over the past decade mobility networks progress was slow and quite stuck for multiple reasons. Many of these reason primarily stem from questionable pre-assumed peer-to-peer model for mobility, and redundant protocol wars that follow - DSRC/c-v2x. Vehicles in most road situations are not really peers, they briefly happen to be in the same place at the same time. An enforced peer to peer model to communicate situations introduces privacy, interoperability, security, timing, and convergence problems which are hard to impossible to solve. As an example, a vehicle reaching a junction and about to turn into an invisible problem (to him) such as construction, jaywalker, double park, school-bus. The problem is clearly visible to cross traffic, but that vehicle may receive multiple, conflicting, or no indications at all from cross cars it doesn't know or trust. To solve this problem we focused strictly on layer3-4 or connectionless brokered mobility sessions. We use the shared-road-location, or geo-state, as the brokering anchor of v2v v2x communications. Nexar, having some of the largest v2v fleets, 10Ks in every major US city, 100Ms miles of ride logs, together with Cisco and academia propose the nexagon draft. Nexagons tiles every road, lane, junction, shoulder, sidewalk with 1sqm H3 hexagons giving each an aggregated unicast and multicast virtual IP (LISP EID) address. These are the in-network geo-state network hexagons enable brokered, verified, private, resilient, LISP based pub-sub exchange of road information. H3 Hexagons offer clear bit operations to track impacted neighboring tiles, clear bitwise geo-spatial hierarchy, approximation of lan-lat-rad that tiles, and algorithmic 64bit HID to 128bit IP EID mapping. We will describe the draft briefly in hotRFC, and few v2v v2x examples including red-light-breach brokered-relayed in under 2msec in lab conditions the largest 5G carrier, as well as real life footage examples from US cities happening daily as time permits. The draft will be discussed at more length in the routing area LISP-WG meeting on July 22. Any questions can be forwarded to lisp@ietf.org or to myself sharon@getnexar.com, or to any of the co-authors listed in the draft. Hope this is clear, attaching a couple links to short video and the draft. https://youtu.be/dK2II3oFzqE https://tools.ietf.org/html/draft-barkai-lisp-nexagon-05 ===================================================================== 6. An open congestion control architecture with network cooperation for RDMA fabric Roni Even (A) The requirement document discusses major problems of current Remote Direct Memory Access (RDMA) fabric technologies and the requirements for better performance. Based on that, the architecture document proposes an open control architecture of hosts and networks for the high performance RDMA fabric to provide better congestion handling for High Performance Computing (HPC) and distributed storage accessing applications which requires low latency and high throughput. We will also have a side meeting to continue the discussion from IETF104. =====================================================================