Skip to main content

Minutes IETF110: raw
minutes-110-raw-00

Meeting Minutes Reliable and Available Wireless (raw) WG
Date and time 2021-03-08 12:00
Title Minutes IETF110: raw
State Active
Other versions plain text
Last updated 2021-04-02

minutes-110-raw-00
# IETF 110 Reliable & Available Wireless (RAW) WG
RAW WG: https://datatracker.ietf.org/wg/raw/about/
RAW documents: https://datatracker.ietf.org/wg/raw/documents/
Meeting materials: https://datatracker.ietf.org/meeting/110/session/raw
These notes: https://codimd.ietf.org/notes-ietf-110-raw

Notetaker: Ethan Grossman

## 1) Intro -- 10 mins
(Chairs)
- Reminder of IPR policies + GenDispatch
- IAB-IEEE 802 coordination
- Current drafts
- Milestones and Charter

Rick doing the introduction, notewell, bluesheets, etc...

## 2) LDACS -- 15 mins
https://datatracker.ietf.org/doc/draft-ietf-raw-ldacs/
(Nils Maeurer)

Wakar Zia: What is coord between ICAO and this draft?
Nils Maeurer: Will be part of this draft. Being standardized and recommended
practice for LDACS within ICAO. Need to cover reliability, good tech to use for
IETF. Nils Maeurer: No feedback on the draft in last few weeks; we request any
of your feedback and we will ask for last call. Rick Taylor: Probably will have
6-8 weeks for last call process. So everyone in WG please read and be sure
we're happy with it before we adopt.

## 3) RAW Technologies (and Architecture review) - 20 min
https://datatracker.ietf.org/doc/draft-ietf-raw-technologies/
https://datatracker.ietf.org/doc/draft-pthubert-raw-architecture/
(Pascal Thubert)

Rick Taylor: Do we want to split out problem statement into separate draft or
is that just making work for ourselves? Maybe more like what DetNet did? Take
to list. Eve Schooler: Discussed earlier but now problem statement is scattered
throughout multiple docs, would be good to emulate DetNet Problem Statement
draft. Abdussalam Baryun: Agree that need to discuss problem statement and use
cases because related to RAW technologies. Regarding 5G includes techs which
are not RAW so would be good to understand differences in these techs or how
they are included in 5G. Interested to get feedback. Carlos Bernardos: Comment
on Technologies: In past IETF, I agreed to review this but I didn't get to it.
Eve Schooler: I did the same. Pascal: Need update from WiFi side. Could move
scheduling from technology to architecture. Finalize document structure then do
detailed reviews. Rick Taylor: So at last IETF we discussed if ready for last
call, but still questions on Problem statement and on WiFi, so we're close but
not ready yet. Rute Sofia has offered to help with the Wi-Fi aspects. Pascal
Thubert: Don't have to wait til next IETF to continue this process. Rick
Taylor: Agree need to provide IP layer across various L2 techs. Maybe the draft
should be called underlying or supporting technologies. PAREO, opportunistic
overhearing may work well for layers where have cross communication but in e.g.
5G or others may not have access to it. So it wouldn't be possible there, maybe
could reword, could provide text for this. Since we are IETF we are IP not Link
layer. Pascal: Agree can be used .11 don't have context so not constrained to
who sends and who recieves. Association. .11p can be multi-point to
multi-point. Rick: There are per-tech link layer sol'ns but wary of trying to
create link layer solutions. Could use Anycast or IP tunnels to create
overhearing. Pascal: Could consider as broadcast MAC, only IP will decide ( on
delivery ) Agree want to rename to "underlying technologies". Need to decide
what will stay. Toerless Eckert: Collect good ideas about what works for L3
from L2, Maybe promote to L2 as they evolve Toerless Eckert: Need to package to
avoid too much detail. Lou Berger: Per list discussion, Difference between arch
and solution space framework. So this is perfect for solution space, but not
the only solution, so doesn't belong in Arch doc. Need multiple framework docs
to focus on each. Rick Taylor: Agree Some Arch is generic and great, fast
turnaround vs PCE; for fine details of e.g. overhearing and PAREO that is
specific to link layer, want to create separate document(s) for that. Georgios
Papadopoulos: Which do you intend to put in separate doc vs at section at end.
Like L2 independent vs dependent? Rick Taylor: Would do it on demand, all in
one doc until becomes too long then split out. Cut/paste to new doc need to
make sure have people to do the work. Pascal Thubert: Intention is to make L2
independent. Not specific to one tech. Rick: Has to be mentioned (e.g. PAREO)
Pascal: Need to move to specifics of IP layer, per discussion at BOF. Rick:
Similar work in DTN WG from delay tolerance deep space work. Contxt graph
routing. Augmented with contact times. Will know when adjacency will form.
Works in space where have minutes or hours, but some of that math is relevant
and could be used here. Pascal: Put this info on mailing list. Satellite paths
are predetermined, know when and where link will appear. We are deailing more
with uncertaintly. So we have a lot of effort to deal with uncertainty. Rick:
Pruning redundant leaves from tree - know when for certain won't have link.
Rick: For path to adoption, we have a milestone for this, Arch framework or
something. Prior to working on implementatiaon, need to have problem statement
and general architecture. So at least some part of this doc needs to be adopted
by WG. Abdussalam Baryun: Will review draft. Make sure meets requirements and
use cases. Arch should be considered after requirements for industry and use
cases. Thanks to Pascal for his work. Rick: Agree. WG re-organizing content it
already has, e.g. pull use cases into sort of requirements doc. Won't produce
formal requirements doc, but describe problem space and use cases driving the
work, e.g. problem statement. Structure not done yet, still massaging ordering
and how held together. Valid point.

## 4) DLEP -- 15 mins
https://datatracker.ietf.org/doc/rfc8175
(Rick Taylor)

Pascal: Understand that DLEP is separating router from modem, but also saw an
RFC where could be over logical thing like tunnel, not just a MAC. Fundamental
to what we are doing there. Can you discuss that? Rick: Simple TCP/IP protocol
- mostly saying connection terminates at local device, not over the wire.
Pascal: But could call every router? Rick: No uses GTSN to enforce one hop to
prevent this. Not designed for multi hop. Not what DLEP is for - does one thing
only, local info about local device. Only produces input to broader picture.
Pascal: But could build something like that. Rick: A building block. Trying to
do just one thing, not boil ocean.

Lou Berger: Comment about Pascal's comment: DLEP is like LMP which came out of
CCAMP. In that environ, does what Pascal says - can leverage PCE and TEAS
approach, just like what you are asking about, but was done in diff't
technologies. Rick Taylor: Can you do a preso on this? Lou Berger: Now is
integrated into routers. Will work with Pascal to get this info into Arch doc.

Lou Berger (from the chat window):
minor point: WRT slide 5, traffic flows can be identified by DSCP or 802.1p-bits

Rick: Where does DLEP reference go in our drafts? Are there extensions to DLEP
that RAW might request?

Carlos Bernardos: Know about DLEP. Use for OAM? Was that done in MANET? Could
be useful for RAW. Rick: Was not done in MANET. Working on hop by hop instead
of end-to-end path. DLEP+IPPM/OAM has some role to play. Maybe some segments
DLEP capable, could maybe spoop OAM probes to emulate? Not sure where to
discuss this.

Toerless Eckert: Example of info exchange between L3 and L2 so if want clean
protocol need to create a clean (abstracted) protocol, so maybe DLEP is an
example of a tool, maybe could have higher level of abstraction?

Rick: Agree DetNet and TSN have defined max latency etc.

Toerless Eckert: Also could abstract even from TSN

Rick: Just meant any deterministic L2, not literally TSN. Could inherit metrics
from DetNet. Could imagine large networks with many wired segments, with some
wireless segments. E.g. connected together with wired.

Toerless Eckert: Want to constrain to what is relevant for DetNet.
Rick: We meet regularly with DetNet. Discuss what to push back to DetNet.

Eve: Low on time, cutting the queue, please take to the list.

## 5) MEC and Use Cases - 15 mins
https://datatracker.ietf.org/doc/draft-bernardos-raw-mec/
https://datatracker.ietf.org/doc/draft-bernardos-raw-joint-selection-raw-mec/
https://datatracker.ietf.org/doc/draft-ietf-raw-use-cases/
(Carlos Bernardos)

Rick: Chairs will ask on list about integration of RAW Use Cases with
industrial req'ts draft.

Carlos: Is the WG interested in working on this?
Rick: (IMO) This is interesting work, maybe too early for detail, but as a use
case of what we're trying to do in RAW. If can export info to external systems
e.g. MEC or consumer systems would be useful. Not sure how much work we can do
on it immediately.

## 6) Requirements for Reliable Wireless Industrial Services - 15 mins
https://datatracker.ietf.org/doc/draft-sofia-raw-industrialreq/
(Rute Sophia)

Rick: Very useful and in depth analysis. How we tie into use cases is TBD - too
much dtail may unblanace use cases - need to cross reference. Discuss on list.
Personally think we should adopt this draft. Good for new readers.

Eve: Agree this level of detail is useful.

Abdussalam Baryun: Agree should adopt, to think about use cases. Regarding DLEP
and MEC docs, maybe after we agree on use cases we can think about thse
specifics. DLEP is a tech needed by RAW networks so it should be included in
Tech document, how to integrae with other techs. Thanks to Stan for DLEP.
Should include DLEP, brings from MANET.

Rick: Note that use cases draft is already adopted by WG.

Eve: Thanks to presenters. If you have comments from the Chat, please copy to
notes. Will remain open for notes for awhile.

Rick: I have made notes on topics to take to list.

## 7) Discussion -- 10 mins
(Out of time)