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

[Aaron Falk <[e-mail]>]

#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