# RAW WG Agenda IETF-115 - London {#raw-wg-agenda-ietf-115---london} Date: Friday, Nov 11, 2022 Time: 9:30-11:30 UTC - Session I -- 120 mins Chairs: Rick Taylor [rick@tropicalstormsoftware.com](mailto:rick@tropicalstormsoftware.com) Eve Schooler [eve.m.schooler@intel.com](mailto:eve.m.schooler@intel.com) Responsible AD: John Scudder [jgs@juniper.net](mailto:jgs@juniper.net) Meetecho: https://meetings.conf.meetecho.com/ietf115/?group=raw Session materials: https://datatracker.ietf.org/meeting/115/session/raw SHARED Notetaking: https://notes.ietf.org/notes-ietf-115-raw Zuilip https://zulip.ietf.org/#narrow/stream/raw Available post session: Recording: http://www.meetecho.com/ietf115/recordings#RAW Note takers: YOUR NAME HERE! Dominique Barthel, Eve Schooler, # 1) Intro - Chairs -- 10 mins {#1-intro---chairs--10-mins} * Administrivia * Document status * Carlos: * Pascal: still owe Janos a review * Carlos: was waiting for other stuff advances before asking for WG adoption of indiv drafts. * John (from the chat): FYI raw-use-cases is on the IESG agenda for December 1. It’s generally good to have incorporated any outstanding review and published a revision no later than a week before the IESG meeting, so November 22 or earlier would be a good (but non-mandatory) goal. * John: the draft-ietf-raw-ldacs has passed with enough IESG votes (https://datatracker.ietf.org/doc/draft-ietf-raw-ldacs/ballot/) and is ready for one final round of reviews by the AD (John) and after that on its way to the RFC editor * Rick: had side meeting on RAW architecture,identifyinf sticking points. Seemed we can make progress. * Rick: arch doc make two new contributions. ..forwarding.. PAREO functions. The arc doc could include the former, and defer the latter for later. * Rick: large group of contributors, large documents. One Editor, all prior authors will be listed as contributors. * Rick: please voice concerns, chairs beleive this will allow make foward progrss. * Carlos: fine will Pascal being Editor. Question about ... Detnet ... * # 2) RAW Architecture - Pascal Thubert -- 60 mins {#2-raw-architecture---pascal-thubert--60-mins} https://datatracker.ietf.org/doc/draft-ietf-raw-architecture/ https://datatracker.ietf.org/doc/draft-ietf-raw-framework/ * Lou's comments on PAREAO now apply to new doc, not blocking arch any more. * text on promiscuous overhearing: did not mean to imply if was specific to radio. The point is that we exploit it. * arch doc meant to including the full picture, not just what's new compared to Detnet * Rick:agree to glossary about mapping between radio terms and Detnet terms. But do use Detnet terms. * Lou: what is a "Track"? * Pascal: please review the definition in the draft and provide comment. To summarize, ... * Lou: in IETF TE, we call this a path. * Pascal: I read the links you provided me with, but not convinced this is the same thing. * Lou: in IETF TE, many pathes (prim, second, ...), the path that is being used ... * Lou: PAREO looks like 1-for-N ..., would orefer sticking to terminology already used at IETF * Pascal: seems we are overlading path term a little more yet again * Pascal: happy to replace subtrack term by path in the IETF term. But Track is collection of maintained potential pathes. * Lou: new technology, align terminology with what's already in place. Should talk to CCAMP group, they've been down this path before * Pascal: * Lou: Detnet has service, supported par a set of path, and ... function that selects a path. See nothing new in what you're describing * Pascal: there is * Balazs: this is deja-vu. In Detnet, had the luxury that TSN guys were in the room, could establish terminology relation * Balazs: regarding Tack, . Flows: in Detnet, member flow and compound flow. * Pascal: bug in Detnet is confusion between water and pipe, flow and path. Arch doc says a flow is mapped to a path. OAM can go through same path, so can observe it. Should not be decided at application layer. * Balazs: dont see it that way. Not application level, done at the edge. * Pascal: if use 5-tuple, fixed. * John: return to previous conversation with Lou. New terms for precision vs. well known/accesible terms pretty close to what we need. Recommend having a precise set of definitions. * John: once you have complete definitions, you can use either term set. * Pascal: controller building statistial picture of network, trying to achieve packet delivery objective. Subset of .. to be called TE path. But need to observe the bugger set, which I call a Track, don't want to call it the same. * Tianji: first timer, first encounter of word "Track". Commenting on the definition on slide 4. Confused. * Pascal: wonderful. Please write down these comments and help improve. * Pascal: even if RAW protects the wrieless access, OAM observes the full path. * PSE only applies to the 2nd use case, the Mesh, a mult-hop wireless track. It does not compute the e2e path that we're talking about. * Tianji: For your statistic terminology, use Track. For downlink, gnodeB, it is not statistic. * Pascal: OAM is layer 3 from client to server, if it goes bad, we switch the radio (don't care if 5G or WiFi) * Rick (chair hat off): re John's comment, In complete agreement, we are a sibling group of DetNet, so if coming from DetNet you can understand the terminology. \[...\] What do you call a link of service function e2e if that fn makes choices between paths? What is that chain of functions? * Pascal: that is not in DetNet * Rick: that is the crux of the problem * Lou: we have a recursive architecture. e2e service independent of service. The collection of services are called e2e. * Rick: as you start to talk about the recursive layers, if you are talking about a particular service functions (whether above or below), there is a pairing within a protection domain, does that service have a name? * Lou:e2e service * Rick: could we replace Track with e2e serivce? * Lou: Yes. Crux from where coming from: figure out the aligned terminology, we can figure out what tech we can re-use prior work - and new tech to define. Tease those two apart. * Rick: if you call it an e2e service at a layer, is it a pipe or a flow? I agree with you on pipes. * Pascal: Picture from Slide 7. PSE operates outside the flow of packets. Not in data plane. Happens asynchronously to the traffic, in the OAM plane, where we will switch the service. * Lou: when switching between services means you are switching between forwarding paths. If I'm an application op'ting at a particular layer, if I go to a layer below, each layer is its own service. Would be super helpful to draw the picture for the wired network. * Rick: PSE is purely a control plane entity. * Lou: PSE is controlled by Yang model driven by a provisioning system. No reason it could not be driven by AI/ML. Architecture only defines one protection switching. contributino driven, you're not adding something fundamentally new, another protcetion switching mechanism, could be considered. * Pascal: there is only one layer of service, and we never go through the control layer for the packet processing and we need to expose that to the user. * Lou: accessible to the reader, but without defining too many new things. Draw this picture (slide 7) for wired, then say here is how it is modified for RAW. Dropped in chat how to do this for MPLS. * Lou: first show how this exists/(works?) for Detnet. * Lou: Accept what the IETF standardized already, whatever your intent was. Multiple examples of the protection services listed in the original doc. * Pascal: we seeme to converge that this is protection function. Don't agree this is a service layer function. We placed it in the forwarding plane. This however is in the control plane, so it needs to be extended to operate there. * Don: Suggest lose the term Track, describe in terms of a Path, and let the WG if there is a term that we need to describe that in the end. That would add clarity to the doc for me. Might reach consensus faster. * Rick: Want to go back to the splitting of the doc. Made to separate the PAREO service fn from the PSE's role in the arch. Agree with Pascal is they are two separate thing. The disagreement with Lou may be that he is saying they are one thing. * Lou: Actually meant to say they are separate. * Rick: PSE in DetNet, unique part of the RAW WG i fast feedback loop part of ... Different from "btw , can produce service function ... within detnet". * Lou: went over drawings (powerpoint) at length when doing the Yang models. Could point at what is new * Lou: will see if can dig it up and send to the ML * Pascal: the model will tell you what you can and cannot do. Because the YANG model is wide enough to do stuff, doesn't mean we do all that stuff; there is a RAW of the model vs architecture. * Rick: two concepts there. In an arch doc, you can say there is a well defined control path between the srv control fns down to the srvcs themselves. In the arch we are going to use this and it exists. * Pascal: if the model allows, doesn't mean we use. Arch defines what we do. Yang is a superset. * Stuart Card: Want to give a perspective of a newbie. Attempted to parse DetNet and RAW docs. Despite an enormous amount of work by both groups, neither particularly accessible by a newbie. There are things that appear in the doc that have a lineage that are difficult for a newbie; have sympathy for newbie, and want to help the newbie by re-using terminology. Yet have a deep appreciation for precision of terminology. Come down on the side of use new terminology for precision. However say "this is what we really mean by Track, but if it makes it easier for you on a first read to replace by Path, do so, but on a second read it will be very important to make the distinction". * Pascal: THANK YOU. Service and Service layer is control plane. Agree with recursive, for compound flows. You certainly nest service layers when have compound flows, but the packet sees the operations, whereas the PSE isn't seen and it isn't forwarding plane. Q: What do we define as service layer? Spent a lot of time trying to make the diagram simple. * Xuesong Geng: Pascal thank you for your explanation, as co-author of DetNet Yang model. Want to make clear more about the PSE. Does it mean that the PSE itself includes the OAM process and the controller plane process and maybe the forward or service layer of DetNet. * Pascal: The PSE talks to the OAM supervisor. Liked OODA because the PSE does the D, the Decide. OO and A are done by other components of the control loop. * Rick: like to think of the PSE as a small, local, stupid, PCE! May not be small or stupid but local. * Pascal: would like to consider to make it more distributed. * Xuesong: PSE is part of control loop. * Pascal: O is Orient, is the intelligence. * Xuesong: want to think more to connect the concepts in RAW and the existing terminology/concept in DetNet. * Rick: If you find areas difficult or incoherent, please post to mailing list. You would be a perfect reviewer. * Tianji Jiang: * Pascal: Loose RAW use case (we only protect the access). Corresponds the closest to the situation we are talking about here. Only thing we see, is what iis at layer 2 and what is at layer 3. DetNet forwarding extends to the gNodeB. We have layer 3 OAM so we can observe when we send something because it is received. We cannot take actions inside the core, we don't see it. Sending OAM packets on all access interfaces (on the phone). Trying to determine which make it. The PSE will decide which interfaces to use (not type of radio because abstracted). * Tianji: you see 5G network as black box? * Rick: once we get the architecture and core docs done, having an ability to understand better OAM for the lower layers (make grey boxes in some sense), to make smarter decisions. Yet have to assume the boxes are black boxes initially. In other words, step I is consider a black box, later perhaps grey box. * Don: is the PSE locally optimizing for each service? * Pascal: Yes it switches which service * Don: what makes that stable? What coordination fn makes it stable? * Pascal: In the current model, at the ingress. Do you mean I have multiple services? They are nested, so it depends on what is going on below. The intelligence is the PCE. \[...\] 2.5 copies of the packet. Did not visualize with multiple services, parallel sets. * Lou: can we get a sense from the room, focus on new terminology that is more precise or leverage existing terminology and refine that. * Pascal: tweak. In between. More of the existing terminology. * Rick: Want to unify familiar terminology (DetNet and wireless worlds). When we talk about it in this document, with some qualifiers. * Room: No one thinks it is a bad idea. * Rick: Is there a US speaker who would like to contribute text to this Don Fedyk's hand. Balazs. * Pascal: you said something that it raised the image that someone would misunderstand. There is a session. PREOF doesn't work like that. For instance, you might have one replication point that makes 2 copies. Might be others doing the same. The single elimination point may not talk to either. There is no session. They must be independent. The design is distributed. * # 3) Discussion/Open Mic {#3-discussionopen-mic}