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 (mauro.cociglio@xxxxxxxxxxxxxxxx)
Massimo Nilo (massimo.nilo@xxxxxxxxxxxxxxxx)
Fabio Bulgarella (fabio.bulgarella@xxxxxxxxxxxxxxxxxxxxxx)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.
- Scalability. On the user device there are few connections to monitor.
- 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-02Presentation:
IETF 108 IPPM WG meeting, 14:10-15:50, Friday Session III, Room 8Hackathon IETF 108 – QUIC Measurement Project.
Opening Monday, July 20, 14:00-15:00
Closing Friday, July 24. 14:00-15:00Video: 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
time2) 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: lispwgVideo: 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 BOFWe 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/LoopsVideo: 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 BOFWe 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/ietf108Video: 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.htmlVideo: 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 USAAbstract:
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 slideVideo: https://youtu.be/jmNICFsqcUc
Slack channel: https://ietf.slack.com/archives/C017QDVQ736
