* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Raw Status Pages

Reliable and Available Wireless (Active WG)
Rtg Area: Alvaro Retana, Martin Vigoureux, John Scudder | 2020-Feb-07 —  

IETF-110 raw minutes

Session 2021-03-08 1300-1500: Room 6 - raw chatroom


minutes-110-raw-00 minutes

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

Generated from PyHt script /wg/raw/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -