# IETF 111 RAW WG ## RAW WG Agenda IETF-111 Date: Tuesday, July 27, 2021 - Session I Time: Tuesday July 27th between 1200-1400 PDT - 19:00-21:00 UTC -- 120 mins Chairs: Rick Taylor Eve Schooler Responsible AD: John Scudder Meetecho: https://meetings.conf.meetecho.com/conference/?group=raw Live minutes: https://codimd.ietf.org/notes-ietf-111-raw Note taker: Ethan Grossman 1) Intro -- 10 mins - Administrivia - Adjacent SDOs - IAB-IEEE 802 coordination - AVNU DetNet Study Group - Document status - Milestones update (Chairs) 2) RAW Technologies and Architecture -- 20 mins https://datatracker.ietf.org/doc/draft-ietf-raw-technologies/ https://datatracker.ietf.org/doc/draft-ietf-raw-architecture/ (Pascal Thubert) 3) Use Cases -- 20 mins https://datatracker.ietf.org/doc/draft-ietf-raw-use-cases/ (Carlos Bernardos) 4) OAM -- 20 mins https://datatracker.ietf.org/doc/draft-ietf-raw-oam/ (Fabrice Theoleyre) 5) Interoperability -- 20 mins (Eve Schooler) /* Still room for other presentations */ 6) Discussion -- 10 mins ## RAW WG minutes IETF-111 Chairs do the usual BCPs note well and agenda bashing Eve presents related work at the IAB - 802 coordination and at the AVNU alliance; AVNU now started a DetNet study group and a wireless TSN study group LDACS was submitted for publication; John (AD) now handling the next steps, AD review then IESG agenda. ### Pascal Thubert: Technologies draft status Mostly stable but need to make sure draft aligns to real world - if wait too long, things go out of date. Since 2 years when started, how much do we need to rewrite to account for changes in technologies? Rocco Di Tarantino: Submitted some comments, what is status of them? PT: Has empty mail about section 4? RT: Please send again, somehow got corrupted in transit. RDT: Should be handled before last call, so will re-send. RT: Will hold draft last call until these comments are considered. Ack that Pascal feels draft is otherewise ready for LC. Rocco from chat: Re-sent and comments can now be found here: https://mailarchive.ietf.org/arch/msg/raw/4afPdkKv9OOLcemZImIaKxVhW6M/ ### Pascal: RAW Architecture/Framework draft status: The architecture describes an OODA loop where OAM observes a Track designed by the PCE. The PCE provides wisdom that orient the per-packet forwarding decision by the PSE. Acion is the use of PAREO at the detnet service sublayer, signalled e.g. by BIER-TE or SRv6. Building track with input from network e.g. OAM/PSE, as well as PCE. Have improved OAM section, added about PAREO. Missing type of messages, data propagated at various places to obtain expected results. E.g. Can do reverse/upstream OAM, but don't know exactly what is captured. Maybe something from DLEP. Haven't integrated e.g. status of links. PSE at ingress requires all info to be in the packet. Maybe could do partially distributed, e.g. via hints on quality, leave to node on path to do e.g. PAREO. Haven't worked out all of this logic yet. Balazs Varga: There is a dedicated OAM doc in RAW - Arch doc also now talking about OAM functionality? Will OAM be in two docs now? Should it be moved to dedicated doc? PT: Working closely between RAW arch, as well as RAW and DetNet OAM drafts. Arch needs to give overall structure for OAM draft to cover in detail. Positions OAM in the loop w/o too much detail. RT: RAW Arch places req'ts on OAM draft? PT: Yes but Arch needs to characterize flows, describe how flows generally operate to provide the req'd info. Details go to OAM doc. BV: Understood. Also DetNet service layer and DetNet Service Plane - does that mean the DetNet Service sub-layer as per DetNet terminology? PT: Yes, where PAREO happens. BV: Use DetNet terminology consistently, DetNet service sub-layer. PT: OK. Lou Berger: Will provide text where add in ability to do multi-layer approach as opposed to integrated approach where RAW and DetNet fully integrated. Will include DLEP info. PT: Thanks for that. Some issues you previously mentioned you would resolve when get more involved with writing - can deal with them, figure out how to do integration. Let me know when you are ready. PT: Need to define how arrival times are to be distributed, if we decide to go that way. Consider Yaakov's draft, need to know which hops and when. Architectural decisions. Some options are on the table e.g. SRV6. RT: Slide says WG LC, meant WG adoption date. PT: Terms: "water" - may also be "other fluids" e.g. OAM. Ethan Grossman: - term "East - West" - is it "left to right" direction per verbal or "Right to Left" as written in the slide? RT: as participant: Flows and tracks - are you planning to reuse work from detnet to assign flows to tracks? Ingress node maps flow to track, but intermediate node makes own decision to move it to another track? PT: Once track is assigned must stay on that track. RT: But do we need more facilities than what DetNet provides for the various data planes? PT: Depends how far DetNet goes - current DN data plane based on 6-tuple flows - we don't want that. I am bringing new work hop by hop, and some SRV6 6MAN work. RT: A new WG on Applications Centric Networking looking at option head fields from an extended DSCP marking? PT: Could be some overlap there, we are doing similar. Need to sync with them. May be enough difference that each needs to do their own version. RT: Flow classification at every node along the track adds overhead? PT: Needs to be done at start ... (??) PT: If can re-use some 6MAN or whatever work, would like to do that. Have shared a lot with DetNet, etc. RT: Don't want to reinvent wheel. PT: SPRING work on PREOF maybe not converging with DetNet, but OK for them to do something different, eventually may find more commonality. Balazs: For OAM for next step need to define RAW req'ts for OAM. Trying to clean up in DetNet OAM framework, clarify req'ts. Then if same is done in RAW can compare notes. PT: Exactly where we are in RAW. Arch must say what we use, where it is defined, point to RFCs, else have to create ourselves. RAW specs will specify what is new. RT: Reverse OAM has isssue with latency on data, so reacting on late data. PT: Yes but way less outdated than what PCE sees. Need to know "the rest of the way" if new conditions arise. Reasons to tune reverse OAM, how many packets can lose, etc. Will be hard. Greg Mirsky: Good point that collecing aggregated metric and reverse OAM might inclur delay. If operator wants to aggregate metrics to reduce OAM packets, then increases latency. Important to point out. PT: Need for instant feedback greater for (??) GregM: Important for RAW, need to express in doc. RT: Out of time, need to continue discussion at end or on list. ### Carlos Bernardos: RAW Use Case draft status: RT: Now have reference to industrial req'ts in this draft - so would probably want to have the WG adopt that draft? CB: Yes would support that. Open question for WG: For some or all use cases, do we need to discuss "non-latency-critical"? Please provide feedback. RG: as participant: Having a section on that sounds good. May not need one in every section. But focus on reliability and availability in applications is good where appropriate: PT: Agree. Have been hinting for awhile, have use cases where mostly protecting access. So RAW addresses "least reliable" part which is wireless. Since dn't do DetNet the whole way can't guarantee latency, but still RAW applies. Eve Schooler: Agree this is important. Is list of use cases complete enough? This could help flesh out more use cases? Agree with RT that don't need for every section, but good to identify those cases. E.g. Use cases in DetNet, e.g. Utilities, a lot there. Applications there where reliability more imp't than latency. So maybe we should add something like that to RAW use cases? Would like to discuss further. CB: Don't have strong opinion, just looking for discussion, thanks for your input. Consider on list. CB: Another question for WG: Do we want a "requirements" section in this draft? Requirements language may be good, but challenging to generalize to all use cases. So may be OK as it is but would like to agree on something. RT: As chair, personal opinion, don't think we need dedicated Requirements section - depend on use case descriptions for that, including industrial. Other drafts could be added. But do like a summary. Valid to say that it doesn't apply to some use cases. Not an absolute list. Presumably at end of document. CB: Need more reviews on this draft. RT: Anyone have time to review this? Corinna Schmitt: Will review. RT: Carlos believes this work is ready for LC, but would like more review, and waiting for whether we adopt Industrial draft. Other review volunteers from chat: Xavier Vilajosana and Adam Wiethuefer (UAS/UAV section). RT: Plan to go to last call after those steps. ### Fabrice Theoleyre: OAM for RAW draft update: RT: Don't want this draft to go to WG LC before RAW Arch doc, since may have req'ts there. OK for it to sit as "WG is pretty much done but blocked on other draft" state. Eve Schooler: Also maybe wait for DetNet OAM drafts to be finished? Fabrice: We meet regularly with DetNet OAM group, so at present the drafts are not that inter-dependent. RT: OK so let's pretend it is ready for LC, but hold. Of course any additional review always welcome. Puts pressure on Arch doc (and WG as a whole) to make progress. OAM is at the core of RAW work. ### Eve Schooler: Topic: Interoperability: An Early Discussion Eve introduces possibilities to do Hackathon in the future. Carsten suggests to leverage "thing to thing" research group (t2trg) model. That is, partner with adjacent standards organizations and industrial forums. Hackathon used as a way for cross-pollination and early interoperability. CB from chat: You need to be modest in your goals and get the low-hanging fruit first. LB from chat: Think the hackathon is a great idea! RT: (as contributor) Concern that when trying to do reliability protocols on top of layer 2, at a Hackathon, short of bringing a lot of dedicated equipment, may be challenging to get it realistic enough to validate anything meaningfully. Is it too much to expect from an IETF Hackathon? Would be interest in hearing other opinions. Adam Weithuechter: Has tried this e.g. in Singapore, was a pain to bring a ton of equipment. Although having week-long hackathon helps, and could do enough pre-planning to make it worthwhile. RT from chat: Agree, that it needs planning! Eve: This is billed as "An early discussion" - maybe we need to do something different than a hackathon? Maybe not at IETF112 but after that? RT: Any dissenting view? Would rather have companines and universities do this kind of thing? Adam: Companies do their own testing, but good to have multiple vendor interop environment. Eve: Want to "showcase" test bed strategies, above and beyond what individual companies do - that's boring. What other strategies can we find for interop testing? Is there precedent for this in hackathon tradition? RT: Not proposing formal verification/certification - IETF doesn't do that. Just to be clear. Want to validate assumptions that have gone into our RFCs but until you check it, you don't really know. Carsten Bormann: Interop testing interesting on its own. Have had a few events where brought to gether implementations, and went through sequence of tests - not a "bench" but just get high level testing. Hackathon less structured, but have more ability to react on the spot to weird things happening. In past had meetings called "interop" and were able to fix things on the spot, very useful. Like a hackathon, but at hackathon not expected to bring complete implementation. Diff't than interop scenario - there need to be "mostly done". Eve: That makes a good model for what we could do for RAW. Not that we "need" to do this, but asking if the WG feels it is important. RT: Over to the floor for any further questions or comments? No further comments, great meeting, it's a wrap. John Scudder: Agree, appreciated discussion with substance.