https://tools.ietf.org/html/draft-ietf-raw-technologies-00
Re: do we want to enforce all technology chapters to have same structure.
Lou Berger: Where does this info show up? Is there a section where IETF technologies show up?
Pascal: This draft is about specific radio technologies, IETF technologies not included here. Background.
A charter item to do this analysis for IETF technologies, the gap analysis - that draft is about link layer (et al) and their capabilities. There are other sections about IETF protocols.
Rick: Personal opinion: Don’t need all sections to have the same format - if a section is important then include it, but don’t fight for symmetry.
Pascal: On deployment and spectrum section, for WiFi 6 would be interesting to have this, what services and when. Big fight for WiFi spectrum - maybe ask WiFi to get a “6.3” section. Maybe projections for deployment. Could be interesting.
Nils: Says (in chat) he can add to LDACS draft.
Pascal: A 6G discussion is at IETF, maybe work with Janos to create? Would be good to hear where 6G is going with respect to determinism.
Rick: What about legacy technologies? All about new techs, not much on legacy. Is that out of scope for this doc?
Pascal: Limited to technologies that can be scheduled, which allow bounded latency. So didn’t go over all non-deterministic radios.
Rick: Could be a work item for WG? Produce a doc about workarounds for legacy?
Chunshan Xiong: Working in 5G 3PP. Question: Have dedicated spectrum for 5G (?)
Pascal: Not sure where more about 5G would fit into this doc - what is suggestion?
CX: Two accesses available fo 5G, multiple path, for reliabliity and throughput. Could improve mobility and throughput and reliability.
Pascal: Agree, that’s why we’re here. Arch has picture of this, WiFi on one stream, 5G on another. For this doc, explaining technology, do you want a section explaining how they work together?
CX: In 5G maybe consider (?)
This is IETF - looking at solutions between heterogenious technologies. 5G may have system for improving reliability within 5G tech space - that’s great but where IETF comes in is when data transitions to different technologies, but still needs the required SLA. So maybe more words in 5G saying is more than just radio for handsets, may be useful for furhter work and analysis, but we don’t need to duplicate what 5G 3PP etc are doing. Want to figure out how they interact with other technologies.
Eve: This doc is to harmonize various technologies, it is groundwork for that.
Pascal: About adoption of this doc - are we missing something? Maybe more about 5G, or about WiFi with 5G underneath, ask authors of that section if they want to add that. Don’t want to change structure dramatically, how to get to last call to approve? Ask for reviewers?
Rick: Agree more review would be good.
Eve: Will review further.
Show of hands: Who has read doc (technologies draft)?
Raise 8, do not 6, total 36
Show of hands: Who will do a thorough review of this draft?
Carlos, Eve, Adam Wiethuechter, (one more?)
Raise: 4, Do not: 7, total 36
https://tools.ietf.org/html/draft-pthubert-raw-architecture-04
Eve: Would be a good place to solicit input
Pascal: Not the right
Rick: For gap analysis that would be its own document.
Section 2 here would be shorter, would call out other drafts
“solving problems as listed in these references” .
Pascal: Structure may need to be adapted, remove some pieces if they are better expressed elsewhere.
Not sure if need prime statement.
Sec 2.2 only couple of pages. 2.4 (related IETF work) would be huge, so better to do as own doc.
Rick: They need to be there so can scope this document. Use cases are general, broad, need to refine them to say framework applies to these use cases - good but need to keep short.
Pascal: “Framework” definition? Packaged into framework and architecture, explaining what can be done, section 3, currently called framework, but maybe rename to “background”? Model inherits from DetNet.
Flow Identification vs Path Identification - 6TiSCH has different tuple than defined in DetNet - decouple path from flow indication, allow multiple flows in a path. Can then have OAM with same 5- or 6-tuple but still distinguish.
2 usual methods: Source/Segment routing, at ingress, put in at start. Here would not linear path but 2-dimensional path.
Pascal: (?) Inherits from 6TiSCH and ROLL
Pascal: Would like feedback today or on ML about structure. So far see that 2.4 could go away when new draft arrives. Same for Arch - did (Pascal) do the right organization? Anything else we need? Pascal feels he is done with it, ready to give to WG.
Eve: So once have done this review step would be ready to ask for adoption?
Rick: Will help with review of this. It is a key part of the work, need to adopt, willing to help. As soon as can get latest draft, WG please read it - interoducts a lot of framework, architecture, tries to set down ideas being discussed informally in a formal manner. So if concepts aren’t clear, now is the time to resolve this.
Pascal: WG adoptions isn’t a guarantee that it will be published eventually, but adoption call would trigger reviews we are talking about.
Eve: So post it, we can read it, then ask on ML if ready to adopt, since fairly mature.
Lou Berger: Filling in some spots, identifying gaps would be good before adoption, good to know what we’re signing up for. Flag what work is, prior to adoption call.
Rick: Would counter that: Doc is critical to WG, what WG is trying to achieve, solve problems in use cases. So personally feel that adopting ASAP keeps momentum in WG.
Lou: Support adoption, once have identified missing things e.g., DLEP and DetNet. Willing to identify more about what is needed to integrate with other IETF technologies. Would not support adoption without flagging those things.
Rick: With chair hat on: Pascal publishes update. Then 4 weeks later have call for adoption - gives everyone time to read and review. Is tech and approach correct? Criteria for deciding. Does this work for Pascal, WG?
Pascal: Would be good if Lou could contribute some of those missing pieces. Can you two help with this in next 4 weeks?
Rick: Yes will make that time.
Or another DetNet LDP expert.
Lou: Will send something to the list once the new revision is posted.
Pascal: Not sure what Lou has signed up for? Need work on Arch doc, want to see how it fits into rest of IETF framework, e.g. DetNet and TE, there is some new text in new version, but Lou could improve a lot. Also discussion on how fits with existing tooling like DLEP, would need to be in Gap analysis, how to describe integration in Arch doc.
Need to structure, decide what goes where.
https://tools.ietf.org/html/draft-ietf-raw-use-cases-00
Questions for WG:
Eve: Chairs discussed this. Concluded that have good collection of use cases, but to get to LC, need to reach out to others in those areas, to determine if they are captured well enough.
Carlos: Will try to recruit others to review.
Rick: This is a WG doc, so WG please reach out to subject matter experts. If you know someone or are a SME, please have a look. Don’t need a huge drilldown essay, just need to make sure relevant info is there and is correct. Make sure everyone in WG is happy with this.
Nils: Will rework some of aeronautics part.
Alexandre Petrescu:
For the UAV platooning use-case - one of the use-cases is the ‘drone show’ using thousands of simultaneously flying drones. But unfortunately these communicate only when on the ground. DO we know when will these drones communicate among them in-flight?
Rick: Could write a lot about UAV swarming - as long as capture general purpose text, will be sufficient.
Pascal: Maybe need link between use cases, where each applies, and how architecture solves the problems, how to glue them together. Conclusion of use case doc is to find common themes to look at. Create link to Arch doc.
Rick: Agree. Needs solid use cases doc, so can refer to it. Can then recharter RAW in the future, so next gen of IETF contributors can solve what is currently out of scope).
Pascal: E.g. need for multiple accesses at same time. Have two abstractions, mesh and … .
Carlos: Would like to turn req’ts section at the end to make link with Arch. Will try to do this in next iteration, with other feedback. Then will get more comments after that. See how to integrate into Arch.
Pascal: Has published new version of Arch draft.
https://tools.ietf.org/html/draft-ietf-raw-ldacs-05
Rick: Question of why are we handling this in IETF/RAW? Is in slide p 13 - keep tower to ground networks operating smoothly. Using alternate technologies, but end to end is important. So LDACS proper may be out of scope for IETF, but making sure it connects to rest of world is in scope.
Pascal: Do we have a case where plane on top would use other planes as a relay to tower, like mesh network?
Nils: Presented air to ground, more mature, but also air-air layer is beind worked on. Relaying from one aircraft to another. But need MAC and PHY procedures defined.
Rick: This use case being explored by aeronautuical companies, but not always at Layer 2, maybe at IP layer, since diff’t manufacturers radios, diff’t security domains, etc.
Eve: thanks for iterating on feedback, look forward to next draft.
https://tools.ietf.org/html/draft-theoleyre-raw-oam-support-04
Rick: Checking charter to make sure OAM is a charter item?
Eve: Not listed in milestones, but is in charter.
Rick: So we need an OAM doc, so WG please review, give authors feedback. Authors are you ready for adoption?
Fabrice: No, not ready yet. Maybe at next IETF.
Eve: We need to reconfigure milestones, need to add an OAM milestone, a bit further out. But need to estimate a time frame with authors.
Rick: looking to rationalize milestones with what is actually being worked on.
Eve: Need to align milestones with charter and deliverability capabilities. Rick: Not increasing scope of work.
Pascal: Back to Architecture - give ourselves 4 weeks? Would like work session to discuss between Lou and Rick to figure out how to make suggested changes. Time is tight.
Rick: Is 4 weeks too long?
Pascal: No, should just adopt, then ask two new authors as only change for 00 revision. Form design team or just authors to do what Lou and Rick want. Could do just between them and authors. But if we know where we’re going, don’t need to wait four weeks.
Rick: Choice of 4 weeks was because no opportunity for WG to read latest version, so need time for that. Consider if correct direction for arch and framework for RAW.
Pascal: Could do the required work in personal contribution.
Rick: Two separate questions: Is there more work to do? Does WG adopt doc?
Lou: Reason for 2 week cutoffs - starting at busy time, should allow 4 weeks to allow time for review. Can’t say “I published it today, let’s adopt today”
Rick: 4 weeks gets us through to start of December holidays. Happy to do show of hands, but need time to consider.
Pascal: Will take the time it needs. If it’s 4 weeks, OK.
Eve: Agree with Pascal - it has been posted, read it, get comments in after this week, hard next week in US due to holiday, but should be able to finish before December holidays at latest. Take it to list. As long as adoption is within this calendar year, fine.
Pascal: People will take it more seriously if call for adoption.
Rick: Point is to have call for adoption at end of 4 weeks.
Eve: Thanks to group for discussion and note taking.
Rick: Might do interim, if not see you at IETF 110…
(hopefully the bluesheet is created automatically somewhere)
Adjourned.