# 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)