[Raw] RAW IETF 113 minutes - Vienna

["Schooler, Eve M" <[e-mail]>]

Hi All,
Thanks to those of you who attended the RAW session at IETF 113 in Vienna (in-person or remote) and contributed to the presentations and discussions. And a big thank you to Corinna and Carlos for serving as in-room delegates - much appreciated! Attached/below/uploaded to datatracker are draft RAW minutes from IETF 113. All corrections/feedback/inputs welcome.
Eve & Rick
------

RAW WG meeting minutes IETF 113 - Vienna

Date: Monday, March 21, 2022 - Session I
Time: 0900-1100 UTC / 1000-1200 CET - 120 mins

Chairs:
Rick Taylor [e-mail]<mailto:[e-mail]>
Eve Schooler [e-mail]<mailto:[e-mail]>

In-room Delegates:
Corinna Schmitt [e-mail]<mailto:[e-mail]>
Carlos Bernardos [e-mail]<mailto:[e-mail]>

Responsible AD: John Scudder [e-mail]<mailto:[e-mail]>

Meetecho: https://meetings.conf.meetecho.com/ietf113/?group=raw
Session materials: https://datatracker.ietf.org/meeting/113/session/raw
Session chat: https://jabber.ietf.org/jabber/logs/raw/2022-03-21.html
Shared notes: https://notes.ietf.org/notes-ietf-113-raw
Video of session: https://www.youtube.com/watch?v=lgTrZJC79ZA

Note takers: Pascal Thubert, Eve Schooler, Lou Berger

1) Intro - Chairs - 10 mins
Administrivia, Meet-echo, Doc status

Rick presents the usual BCP on IPR etc.
Asking for notetakers.
Eve on agenda bashing.

2) LDACS - Nils Maeurer - 10 mins

https://datatracker.ietf.org/doc/draft-ietf-raw-ldacs/

Updates to various sections: Motivation and use cases, Requirements, with biggest changes to Normative References that provides further readings.
Appendix targets aeronautical communications context.
Changes to the motivation and use cases section focused on security and regulatory requirements.
Aero networks are Multi domain architecture (e.g., cabin vs. entertainment), each kept strictly separated, and this is happening in LDACS as well.
Corinna (via chat): just published version 10 of LDACS doc: https://www.ietf.org/archive/id/draft-ietf-raw-ldacs-10.txt
Rick: Did the draft address all of John's review comments?
John Scudder: appears so. I think we're ready, will start IETF LC this week.

3) Use Cases - Carlos Bernardos - 10 mins

https://datatracker.ietf.org/doc/draft-ietf-raw-use-cases/

Carlos presents on site.
Wide range of uses cases in the draft, e.g., aeronautical comms, amusement parks, wireless for industrial, pro A/V, wireless gaming, UAV and V2V platooning, etc.
At last IETF highlighted requirements for RAW, particularly non-latency critical considerations.
Thank you to Pascal and Corinna for reviews. All comments are addressed. Additional improvements as well.
Publication was requested, waiting for IETF LC comments.
Rick: thanks for the work, this is next in John's queue when he has the cycles.

4.1) RAW Architecture - Pascal Thubert - 30 mins

https://datatracker.ietf.org/doc/draft-ietf-raw-architecture/
Generic concept is to balance reliability & availability with energy & bandwidth.
Need to find engineering methods to achieve this.
Architecture provides an overview of what we will do, providing the broad picture before the actual work is completed: provide terminology, reliability and availability in the context of the IETF, conceptual model with OODA loop, introduction to the Path Selection Engine (PSE).
Framework's scope on the otherhand is how we achieved it, and the selected building blocks and their interactions.
First thing to agree upon is the terminology.
In particular, want to distinguish between the use of the term "path" and "track".
Path typically used to describe a linear sequence of nodes, as opposed to a multi-dimensional graph, since - with DetNet and RAW - a packet may be duplicated, fragmented and network-coded.
The various byproducts may travel different paths that are not necessarily e2e between A and B.
A more complex path.
Need more discussion with Lou to agree on the nuances of Track definition.
Reference to DetNet [RFC8655] for clarification.

Need also to identify the Flow (the water), a collection of consecutive IP packets defined by the upper layers and signaled by the same 5- or 6-tuple.
Packets of the same flow must be placed on the same Track to receive an equivalent treatment within the Track (that serve as the Pipes for the water).
Multiple flows may be transported along the same Track.
The subTrack that is selected for the flow may change over time under the control of the PSE.
Rick: wary of defining terms separate from DetNet. How/why is this different?
Lou: Agree that there is a similarity here, and some nuanced differences.
Pascal: will address at end of presentation.
Lou: are we really limited to IPv6?
Pascal: we can discuss this at the end as well.

OODA Loop enables continuous adaptation to continuously changing environment.
Source:

Is there always a PCE or not? We need to align on that.
Although no specific protocols are proposed, DLEP is used here, but as a broad term, implying a family of protocols.

Thank you to Fabrice and Dave Cavalcanti for reviews.

Pascal: will remove reference to IPv6 in the sentence Lou points out (on the mailing list)
Carlos: do you foresee future control extensions, e.g., AI-based decisions in RAW networks?
Pascal: the way it's described right now, the intelligence would reside in the central controller (note Lou's question is there always a central controller). It is all statistics. The experience could be translated/transformed however. Fitting the learning into the Decision making. Do you distribute to more nodes in the graph? One would need some signalling to perform that.
Rick: sort of agree with Carlos on this, and I know I owe a review. The logical architecture is good, in terms of PCE and PSE elements. As a logical separation of responsibility it is a good model, but it needs to be extended down; the PCE needs to communicate with an OAM (north and southbound interface with L2). Further clarification needed in the document.
Pascal: Could probably improve the PCE and PSE interaction descriptions.
Rick: separate the logical concepts from the actual mechanics of doing this (e.g., active vs passive). If doing AI-predicted prediction, then it influences this part of the architecture.
Lou: the PSE combines two functions. Determination of which tracks are available, and on a per packet basis which ones are used. These are concepts that exist already in general engineering (e.g., a protection segment or path). If use older terminology, then could leverage the functionality associated with those terms. Might help delineate the concepts and the functions possible.

Rick (via chat): I think it is useful to have a PCE construct in the architecture, even if a single PCE instance is inapplicable in all cases
Lou (via chat): Do only PCE-based solutions fit into the architecture?
Rick (via chat): I believe the intent of the contentious section is to demonstrate the difference in control-cycle time between the "policy" components (e.g. PCE), vs the "reactive"/PSE components
Lou (via chat): I agree this needs to be covered, but just not in a restrictive way
Rick (via chat): Agreed - I like the intention of the section, but the wording needs work to not paint us in a corner
Lou (via chat): right, most of the "words" in the document are good, but needs some important "tweaks"

Pascal: This is very helpful feedback, with your TEAS expertise.
Rick: Advised at the outset not to come up with new terminology. Historically-traversed vs future paths to follow.
Pascal: Be aware that the term Track exists in 6TiSCH and ROLL for the exact same concept as here, so we're not inventing the term either.
Rick: Framework doc to be discussed next time. Interim meeting held re architecutre/framework split and plans to have regular meetings as the docs evolve. Framework meant to be a living document.
Eve: The past meeting was not an official "interim" meeting, but rather the beginning of a series of meetings focused on the architecture/framework docs.
Lou: Actually though, a formal interim meeting might force more attention and get wider involvement.
Pascal: Request to get the references to the historical terminology in place before discussion.

4.2) RAW Framework - Pascal Thubert - 10 mins

https://datatracker.ietf.org/doc/draft-ietf-raw-framework/

The question raised in the review from Dave: Do you serve the use case of the 1st hop, through the wireless network?
Anticipated to address the use cases and reqs served, scope of the work/applicability, the id'ing tracks, paths, and flows, source routing vs distributed PSE, OAM and metrics.
Expectation that this is the living document that outlines the solution; when finished, we will know how it all works and fits together.
The key use case considers wireless access diversity.
How we signal the path on which we place the flow, how we split the path into the experience into the subtracks (tracks within tracks going e2e between ingress/egress).
What do we need to do? Roadmap decided earlier.

  *   Select appropriate radios and effective use cases. Done.
  *   Adapt per-packet activity of a RAW flow along a diverse path.
  *   Enable i/o OAM (in and out-of-band).

Pascal: May need to add a section on interaction of PCE and PSE.
Pascal: TEAS may not be mentioned sufficiently - may need to add to the list of protocols to leverage (on the last slide in the presentation).
Rick: Talking about PCE and PSE control plane smacks of NetConf.
Pascal: Could be that. Either we point elsewhere, or provide hints for more details for that comms.
Rick: How that info is carried is not in scope for the WG at the moment. If someone wants to sketch a YANG model, then NetConf could be used. Let's not burn too many cycles on that just yet.
Pascal: Agreed.

5) OAM support - Fabrice Theoleyre - 15 mins

https://datatracker.ietf.org/doc/draft-ietf-raw-oam-support/

Since v02 was last presented, one update focused on the list of requirements (items that MUST be provided) and recommendations (SHOULD be provided) for OAM in a RAW domain.
Also added was piggybacking, the technique of inserting additional information in an existing packet, e.g., additional (control) headers and packets back-to-back (if < MTU).

6) Multidomain extensions - Carlos Bernardos - 15 mins

https://datatracker.ietf.org/doc/draft-bernardos-raw-multidomain/

Purpose is to present a problem which is not clearly in scope of the WG: multi-domain operation.
Current scope focuses mostly on single-domain.
Identify multi-domain gaps, e.g., in large factories where nets might be org'd in domains (per production lines or buildings/sites).
In the doc, we do not go into how the domains are connected or how the nodes are aware that the multi-domains are interconnected.
Intent: foster potential discussion.
However coordination between PCEs outlined, where the SLA needs to be maintained in each domain.
Rick: Lou has put a link in the chat about multi-domain problem statement coming from TEAS.
Lou (via chat): Some background on multidomain: https://datatracker.ietf.org/doc/html/rfc7926
More good background: https://datatracker.ietf.org/doc/html/draft-ietf-teas-rfc3272bis
Eve: Multi-domain is hinted at in the DetNet charter using different terminology, e.g., DetNet to function across "coordinated domains".
Lou: Yes, it is already in there.
Rick: Are you asking, Carlos, for WG adoption?
Carlos: Not just yet, but raising the topic.

7) Discussion/Open Mic

Rick: Earlier, we referenced radio-specific properties to be discussed, as link-awareness or OAM knowledge for info exchange between PCE and PSE. MANET, in the next session, to discuss DLEP re Channel assignment, frequency bandwidth, and other radio properties.
Eve: Many thanks to Corinna and Carlos for helping out as in-room delegates, and also Thank You to all the authors and reviewers for their inputs to progress the WG documents.