Subject: Virtual HotRFC lightning talks for IETF-108

From: "Aaron Falk" <[email-masked]>
Date: Tue, 07 Jul 2020 08:38:57 -0400

*Do you have an idea, problem space, or proposal that IETFers should 
hear about?*
*Do you want to propose IETF work but aren’t sure if your idea is 
ready or who will be interested?*

Agenda requests are now being accepted for the Request for Conversation 
(HotRFC) lightning talk session. Presenters will submit a 4 minute video 
to make their case for collaboration. Interested folks can continue the 
discussion online. Goals include encouraging brainstorming 
conversations, helping new work proposals find collaborators, raising 
awareness of relevant work going on elsewhere, and promoting BarBoFs.

We’re going to try to preserve the value of this session while 
adapting it to a fully online meeting.  Keep in mind this is an 
experiment and feedback is welcome to improve it should we be in this 
situation again.  With that as prologue, here is how we’ll do it this 
time:

* To request a slot, submit a short abstract to [email-masked] that 
includes the following
  * Talk title
  * Presenter, Affiliation
  * Short topic abstract (topics should be IETF-related in some way)
  * Coordinates to learn more, contact those involved, &/or relevant 
meetings
* All talks will be presented via pre-recorded video
  * To submit a talk, send a link to a YouTube video to [email-masked] 
no later than 2400 UTC July 21, 2020
  * VIDEO MUST BE NO MORE THAN 4 MINUTES IN LENGTH (longer videos will 
be rejected)
  * We will aggregate the videos into an IETF-108 HotRFC YouTube 
playlist on the [IETF YouTube 
channel](https://www.youtube.com/user/ietf)
* We will provide a Slack channel for each talk to facilitate 
discussion.
  * Slack has been selected because it is lighter-weight than dedicated 
email lists and supports asynchronous messaging with history.  (Recall I 
said this was an experiment. :)
  * Assuming no hiccups, the playlist and channels should be up around 
July 22.  I’ll send a note to the IETF & 108attendees when they are 
ready.

Past HotRFC topics have included proposals for new standards work, 
updates on relevant technologies, highlights of cross-area IETF work, 
potentially relevant research, and industry advances that could affect 
IETF participants. With strict time limits, concise talks will give 
viewers a sense of whether they’d like to know more and, importantly, 
coordinates on how to do so.

I hope you’ll tune in.

--aaron

---

From: Aaron Falk <[email-masked]>
Date: Tue, 14 Jul 2020 10:07:48 -0400

Reminder: the submission deadline for HotRFC is one week from today.
--aaron

On Tue, Jul 7, 2020 at 8:38 AM Aaron Falk <[email-masked]> wrote:

> *Do you have an idea, problem space, or proposal that IETFers should hear
> about?*
> *Do you want to propose IETF work but aren’t sure if your idea is ready or
> who will be interested?*
>
> (HotRFC) lightning talk session. Presenters will submit a 4 minute video to
> make their case for collaboration. Interested folks can continue the
> discussion online. Goals include encouraging brainstorming conversations,
> helping new work proposals find collaborators, raising awareness of
> relevant work going on elsewhere, and promoting BarBoFs.
>
> We’re going to try to preserve the value of this session while adapting it
> to a fully online meeting. Keep in mind this is an experiment and feedback
> is welcome to improve it should we be in this situation again. With that as
> prologue, here is how we’ll do it this time:
>
>    - To request a slot, submit a short abstract to [email-masked] that
>    includes the following
>       - Talk title
>       - Presenter, Affiliation
>       - Short topic abstract (topics should be IETF-related in some way)
>       - Coordinates to learn more, contact those involved, &/or relevant
>       meetings
>    - All talks will be presented via pre-recorded video
>       - To submit a talk, send a link to a YouTube video to
>       [email-masked] no later than 2400 UTC July 21, 2020
>       - VIDEO MUST BE NO MORE THAN 4 MINUTES IN LENGTH (longer videos
>       will be rejected)
>       - We will aggregate the videos into an IETF-108 HotRFC YouTube
>       playlist on the IETF YouTube channel
>       <https://www.youtube.com/user/ietf>
>    - We will provide a Slack channel for each talk to facilitate
>    discussion.
>       - Slack has been selected because it is lighter-weight than
>       dedicated email lists and supports asynchronous messaging with history.
>       (Recall I said this was an experiment. :)
>       - Assuming no hiccups, the playlist and channels should be up
>       around July 22. I’ll send a note to the IETF & 108attendees when they are
>       ready.
>
> Past HotRFC topics have included proposals for new standards work, updates
> on relevant technologies, highlights of cross-area IETF work, potentially
> relevant research, and industry advances that could affect IETF
> participants. With strict time limits, concise talks will give viewers a
> sense of whether they’d like to know more and, importantly, coordinates on
> how to do so.
>
> I hope you’ll tune in.
>
> --aaron
>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 17 Jul 2020 16:46:16 +0200

Hi Aaron,

So.. i am wondering if the HotRFC logistics written down below is
complete, or if there is going to be an actual time slot when the
videos will be shown.

If its ONLY whats written down and there is no dedicated slot, it would still
be highly valuable to have an entry in the IETF agenda for it so folks will
find i easier.

Cheers
    toerless

Given how it looks as if the videos are expected to be accessible from Jul 22nd,
it sounds as if there might be no dedicated one-hour slot ??

Is there a target time slot for HotRFC ?

On Tue, Jul 14, 2020 at 10:07:48AM -0400, Aaron Falk wrote:
> > *Do you want to propose IETF work but aren???t sure if your idea is ready or
> > who will be interested?*
> >
> > We???re going to try to preserve the value of this session while adapting it
> > prologue, here is how we???ll do it this time:
> >
> >       around July 22. I???ll send a note to the IETF & 108attendees when they are
> >       ready.
> >
> > sense of whether they???d like to know more and, importantly, coordinates on
> > how to do so.
> >
> > I hope you???ll tune in.
> >
> > --aaron
> >

> -- 
> 108attendees mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/108attendees

-- 
---
[email-masked]

---

From: "Aaron Falk" <[email-masked]>
Date: Fri, 17 Jul 2020 10:50:06 -0400

Hi Toerless,

The idea is to have a fully asynchronous session.  Once the videos are 
posted, discussion can happen on Slack at any time.  I agree it would be 
helpful to have something in the agenda as I’m compiling abstracts and 
I think folks may find them useful to consult in advance.  I’ll ask 
the secretariat if they can support an agenda entry that doesn’t 
include a time.

--aaron

ps.  I’ve received only two slot requests.  I hope others are thinking 
about submitting.

On 17 Jul 2020, at 10:46, Toerless Eckert wrote:

>>> hear
>>> conversations,
>>> updates

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 17 Jul 2020 17:40:06 +0200

On Fri, Jul 17, 2020 at 10:50:06AM -0400, Aaron Falk wrote:
> helpful to have something in the agenda as I???m compiling abstracts and I
> think folks may find them useful to consult in advance.  I???ll ask the
> secretariat if they can support an agenda entry that doesn???t include a
> time.

Thanks. Good to know, as we want to make a submission, but will probably
not be available at the usual sunday slot.

Cheers
    Toerless

> --aaron
> 
> ps.  I???ve received only two slot requests.  I hope others are thinking
> about submitting.
> 

-- 
---
[email-masked]

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 20 Jul 2020 08:30:38 -0400

Reminder: cutoff for HotRFC submissions is tomorrow: 2400 UTC July 21, 
2020.

On 7 Jul 2020, at 8:38, Aaron Falk wrote:

> Agenda requests are now being accepted for the Request for 
> Conversation (HotRFC) lightning talk session. Presenters will submit a 
> 4 minute video to make their case for collaboration. Interested folks 
> can continue the discussion online. Goals include encouraging 
> brainstorming conversations, helping new work proposals find 
> collaborators, raising awareness of relevant work going on elsewhere, 
> and promoting BarBoFs.
>
> situation again.  With that as prologue, here is how we’ll do it 
> this time:
>
> email lists and supports asynchronous messaging with history.  (Recall 
> I said this was an experiment. :)
> viewers a sense of whether they’d like to know more and, 
> importantly, coordinates on how to do so.
>
> I hope you’ll tune in.
>
> --aaron

---

From: "Aaron Falk" <[email-masked]>
Date: Wed, 22 Jul 2020 09:21:50 -0400

#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 ([email-masked])
Massimo Nilo ([email-masked])
Fabio Bulgarella ([email-masked])

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.

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

---

From: "Aaron Falk" <[email-masked]>
Date: Wed, 22 Jul 2020 11:20:59 -0400

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:

> language for kinds of IoT devices, and the Non-Working-Group forming 
> BOF on Tuesday, 2020-07-31, 1100Z.
>