Minutes IETF111: raw
minutes-111-raw-00

#  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 <rick@tropicalstormsoftware.com>
  Eve Schooler <eve.m.schooler@intel.com>
Responsible AD: John Scudder <jgs@juniper.net>

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.