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

Eve Schooler
eve.m.schooler@intel.com

Responsible AD: John Scudder 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

• 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

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