Re: [108attendees] Virtual HotRFC lightning talks for IETF-108

[Aaron Falk <[e-mail]>]

To get access to Slack, all you have to do is click this link, enter 
some details, and you're in:

https://join.slack.com/t/ietf/shared_invite/zt-frvduilu-k9UfPr3sAelv_XPptqJ4wQ

On 22 Jul 2020, at 9:21, Aaron Falk wrote:

> #HotRFC Abstracts & Links
>
> HOWTO:
> 1. Find an abstract you are interested in below
> 2. Watch linked video
> 3. Discuss in slack channel or suggested forum
>
> ---
>
> ##1. How to measure Network Performances with user devices
>
> Mauro Cociglio ([e-mail])
> Massimo Nilo ([e-mail])
> Fabio Bulgarella ([e-mail])
>
> Abstract
>
> After Spin bit introduction, and now with packet loss measurement
> proposals, the Explicit Performance Monitoring on client-server
> protocols (e.g. QUIC) becomes an interesting topic for Telco.
> Explicit Performance Monitoring enables a passive Observer to measure
> delay and packet loss only watching the marking (a few bits) of
> production traffic packets.  We propose that the first place where to
> put the Explicit Performance Observer is on the user device
> (e.g. mobile phones, PCs).  Two main reasons of this choice.
>
> 1. Scalability. On the user device there are few connections to
>    monitor.
> 2. User device and network probes coordination.
>
> It’s possible to set alarm thresholds on the user device (and to
> signal to network probes to monitor only the sessions with
> impairments, in order to segment the performance measurements and to
> locate the faults). In this case network probes, also embedded into
> network nodes, need to monitor only a limited number of connections
> (the ones that have problems).
>
> Coordinates
> Explicit packet loss measurements draft:
> https://tools.ietf.org/html/draft-cfb-ippm-spinbit-measurements-02
>
> Presentation:
> IETF 108 IPPM WG meeting, 14:10-15:50, Friday Session III, Room 8
>
> Hackathon IETF 108 – QUIC Measurement Project.
> Opening              Monday, July 20, 14:00-15:00
> Closing                Friday, July 24. 14:00-15:00
>
> Video: https://youtu.be/YYTPVNGpUog
>
> Slack channel: https://ietf.slack.com/archives/C017GSPSG13
>
> ----
>
> ##2. Segment Routing Multicast
>
> Huaimo Chen, Futurewei
>
> Abstract:
> Seven years ago, a number of drafts about Segment Routing (SR) were
> presented in IETF. SR eliminates the states in the core of a network
> for any point-to-point (P2P) path or tunnel, which is used to
> transport the traffic across the network. This improves the network
> scalability greatly. SR is widely deployed now. However, there is no
> solution for SR Point-to-Multipoint (P2MP) path/tree or SR Multicast,
> which transports the traffic from the ingress of the path/tree to the
> multiple egresses/leaves of the path/tree in a SR domain and no state
> stored in the core of the network for any SR P2MP path. We proposed a
> solution for it and submitted a new draft in PIM working group to be
> presented in details there in IETF 108.  In our solution, there is no
> state stored in the core of the network for any SR P2MP path like any
> SR P2P path. We will present the solution in a high level in HotRFC
> and would like to get your feedback from architecture to some
> technical details.
>
> Video: https://youtu.be/X8Wwyok6xzg
>
> Slack channel: https://ietf.slack.com/archives/C017GSR1V9T
>
> ----
>
> ##3. lisp-nexagon
>
> Sharon Barkai, Nexar
>
> Abstract:
>
> Peer to Peer mobility networks have been standardized in the past but
> require augmentation in the form of multi-point to multi-point
> geo-spatial IP channels. Mp2Mp is realized using high-function
> hair-pinned aggregation between senders and receivers. They are needed
> for the following reasons:
>
>   1) vision: its an extra mobility sensor becoming pervasive but when
>      reporting goes beyond what cars sense, its hard for peers to
>      compile a world view of for example a junction out of the
>      multiple perspectives of the other peers. Its much easier for an
>      aggregation that maintains the observed location state through
>      time
>
>   2) global: multiple applications require current state snap-shot of
>      whats happening in the streets not just immediate peers. Curb
>      parking, blockages, construction are some examples, but more
>      importantly AV-OSS. AV fleets require remote operation supports
>      capacity for catching “confusing” dynamic situations. When 
> these
>      arise it is important to steer AVs clear of these locations not
>      to max-out AV-OSS through shared global tile state.
>
>   3) platoon pub-sub: AV operations is expected to make extensive use
>      of platooning. Remote operated “locomotive” cars pickup AV 
> cars
>      as they go based on where they are and where they are
>      going. Mp2Mp geo-spatial IP channels is a good base layer to
>      convey both location and destination as well as enough
>      information for AVs to be able to lock-on on their own.
>
> The draft-lisp-nexagon rfc itself is a relatively simple informational
> which specifies how to use lisp overlay logical IPv6 addresses (EID)
> as geo-spatial functional hair-pins (convert H3 res9 tile IDs to
> EIDs). EIDs are also used as ephemeral pub-sub credentials through
> diameter allocation along with XTR anchoring coordinate. It specifies
> how to use lisp signal free mcast (s,g) channel registration to
> receive updates based on location and theme of interest. Source and
> Group are also lisp EIDs.
>
> The channel structure enables brokering of legacy BSM messages but In
> addition it specifies a 64bit where 64bit what format for vision
> information. Vision enumerations are 64bit and tied to H3 res15 64 bit
> tile IDs based on Berkeley Deep Drive consortium
> specifications. Finally it has reserved enumeration flags for
> platooning, for example lock-on via 1 byte flag 7byte license plate
> enum for autonomous visual lock.
>
> Coordinates to learn more, contact those involved, &/or relevant
> meetings: lispwg
>
> Video: https://youtu.be/dK2II3oFzqE
>
> Slack channel: https://ietf.slack.com/archives/C017QDRSJ3W
>
> ----
>
> ##4. LOOPS BOF @ IETF108
>
> Carsten Bormann, TZI
>
> Abstract:
> Local Optimizations on Path Segments: IETF 108 Working-group forming 
> BOF
>
> We briefly discuss the objectives for LOOPS, in-network recovery for 
> lost packets, and the Working-Group forming BOF on Friday, 2020-07-31, 
> 1100Z.
>
> Coordinates to learn more, contact those involved, &/or relevant 
> meetings:
>
> https://github.com/loops-wg/charter
> https://www.ietf.org/mailman/listinfo/Loops
>
> Video: https://youtu.be/AM0KdyqMYOA
>
> Slack channel: https://ietf.slack.com/archives/C01883MPHLY
>
> ----
>
> ##5. ASDF BOF @ IETF108
>
> Carsten Bormann, TZI
>
> Abstract:
>
> A Semantic Definition Format (SDF) for Data and Interactions of Things
> IETF 108 Non-working-group-forming BOF
>
> We briefly discuss the objectives for ASDF, a common data modeling 
> language for kinds of IoT devices, and the Non-Working-Group forming 
> BOF on Tuesday, 2020-07-31, 1100Z.
>
> Coordinates to learn more, contact those involved, &/or relevant 
> meetings:
>
> https://onedm.org
> https://www.ietf.org/mailman/listinfo/ASDF
> https://github.com/one-data-model/ietf108
>
> Video: https://youtu.be/mGPma1wAM4U
>
> Slack channel: https://ietf.slack.com/archives/C017GSTUHN1
>
> ----
>
> ##6. JSONPath standardization @ IETF108
>
> Carsten Bormann, TZI
>
> Abstract:
>
> JSONPath has been around since 2007 for selecting positions in and
> subtrees of a JSON document.  It has never been formally standardized.
> Now is about the time, and we have a slot at the DISPATCH WG meeting
> to discuss how.
>
> * Coordinates to learn more, contact those involved, &/or relevant 
> meetings:
>
> https://goessner.net/articles/JsonPath/
> https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html
>
> Video: https://youtu.be/Ujch6Wukjc0
>
> Slack channel: https://ietf.slack.com/archives/C017J8D4ZEW
>
> ----
>
> ##7. Move beyond the ossified Forwarding Plane
>
> Toerless Eckert, Futurewei USA
> Alexander Clemm, Stewart Bryant, Uma Chunduri, Futurewei USA
>
> Abstract:
>
> Motivation and explanations to establish forums and research group
> activity to look beyond the current ossified forwarding plane.
> (network layerr & friends).
>
> Slides: 
> https://github.com/network2030/meetings/blob/master/v108-hotrfc/hotrfc-slides-ppt.ppt?raw=true
>
> Contacts/see-also: authors in first slide, references, side-meeting in
> last slide
>
> Video: https://youtu.be/jmNICFsqcUc
>
> Slack channel: https://ietf.slack.com/archives/C017QDVQ736