* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Raw Status Pages

Reliable and Available Wireless (Active WG)
Rtg Area: Alvaro Retana, Martin Vigoureux, John Scudder | 2020-Feb-07 —  

IETF-112 raw minutes


minutes-112-raw-01 minute

          RAW WG Minutes IETF-112Date: Tuesday, November 9, 2021 - Session I
          Time: 1200-1400 UTC – 120 mins
          Rick Taylor rick@tropicalstormsoftware.com
          Eve Schooler eve.m.schooler@intel.com
          Responsible AD: John Scudder jgs@juniper.netMeetecho:
          Session materials: https://datatracker.ietf.org/meeting/112/session/raw
          Shared notes: https://codimd.ietf.org/notes-ietf-112-rawNote taker:
          Eve Schooler1) Intro – Chairs - 10 mins
          Administrivia - Big thank you to Ethan Grossman for many sessions of
          note taking
          Document status - LDACS in RFC IESG review; adopted the Industrial
          Requirements draft after last IETF, will be renamed shortly; MEC-related
          drafts evolving; other WG I-Ds to be discussed this session
          Milestones update - need to set more realistic dates for some of the
          docs before re-submitting for AD approval
          2) RAW Technologies and Architecture – Pascal Thubert - 20 mins2a)
          to have architecture and framework together.
          Architecture should focused on direction, something you do ahead of time.
          Framework is more about what we built, delivered when we finish the WG
          Q: Should we split the document
          A: We are in agreement. The charter states the WG should explore the
          problem space.
          Pascal: the document is actually structured in a way that would be easy
          to split.
          Lou: Welcome others to join the effort to get the text there. Basically,
          the current root of the comment is that the archtiecture is missing
          the cross-layer or multi-layer optimization that is covered in much of
          the TEAS work and the Internet traffic engineering principles where you
          can have cooperting network layers that each do their own optimizations
          instead of a single integrated optimization approach. That’s really
          important when you have one set of technologies or one set of operators
          supporting another set of operators. For example, when you are running
          DetNet over a 5G network, we wouldn’t expect unless you were the
          5G operator that you would be able to have full access to the full 5G
          network. Liaison came in a year ago or so, where 3GPP said here are
          the parameters you’d need across a 5G interface. We therefore need to
          bring in the concept of multi-layer and bring in DLEP for that. To make
          progress, bring in others for inputs.
          Pascal: In DetNet, something they do very well, e.g., with OAM, they
          have they have these periodic meetings where anyone can join, but still
          it is a dedicated periodic meeting run by the WG. Great progress in OAM
          as a result. Have RAW WG shepherd these kinds of periodic meetings.
          Lou: Make these informal periodic meetings vs interim meetings.
          Rick: We’ll work out the particulars of making a WebEx channel
          Abdussalam: Do not split the draft just yet. Split later than earlier
          (e.g., v05).
          Rick: That’s a valid point.
          Pascal: Want to make sure the docs in isolation are complete. For now,
          could make two separate sessions. If want to make progress on the
          architecture, then need to focus there.
          Rick: If both docs are WG docs, perhaps just keeping it in one doc is
          not as convenient as we think.
          Janos: Two comments and a question. Fully agree with Lou’s comment that
          the architecture should follow layering and be capable of supporting
          all the RAW technologies. Focus discussions could be helpful to
          move along. Question: uncertain on the aspects of the framework vs
          architecture. Which is more of a solution, one or the other? Both of them
          are stepping into solution. Even if do split, not sure on the order. The
          one that is less of a solution would be first.
          Rick: the natural split is between a high-level description of proposal
          versus a detailed proposal.
          Pascal: Framework gives details of how it all works.
          Rick: might also resolve a question on the mailing list. Technologies
          that are in progress in other SDOs like 3GPP or WiFi that haven’t been
          standardized yet. Should we refer to it because it is a standard? In
          the architecture, one could say technologies at the link layer are
          being developed at the link layer. But in the framework doc, one says,
          we use technology XYZ that has been standardized already. Architecture
          can talk about the future, framework a snapshot of the current.
          Abdussalam: Framework is above the Architecture, so anything in
          the architecture will affect the framework, but not the other way
          around.Pascal: summarizes what we want to see in the architecture so far.
          OODA loop with 3 new steps:Observe (OAM), Orient (PCE), Decide (PSE),
          Act (PAREO)
          PSE at Ingress.
          Not a term from the IETF, but quite an old term.
          Observe and Orient = based on prior knowledge.
          Decide = per packet decision, and decides how to forward in wireless
          Act = the forwarding plane action.
          Described the DetNet Service Plane by enrich DetNet, including PAREO,
          timing, and source-routing extension information like the hints and
          Status of draft: v01 stable since last IETF, awaiting updates from Lou.
          What’s missing? Yaakov’s work/SRv6, Lou’s comments re DLEP, IPv6
          encapsulations e.g., use of HbH, DOH and SRH
          Improved the terminology.
          Something less clear in the DetNet architecture is the distinction between
          the flow (water) and the path or Track (the pipe). All the packets on
          the same Track receive the same treatment or processing.
          In RAW a Track may fork and rejoin to enable the PAREO operations.
          For many WGs, a Path is sequential. Thus using the term Path is misleading
          for RAW, so we gravitate to use the term Track.
          Rick: Is a SubTrack a Path?
          Pascal: Not really. If you wanted to trace a path of a packet in this
          context, the concept is complicated and likely gone.
          Lou: What you are describing matches well with the notion of protection
          paths that have shown up with MPLS, DetNet with PREOF, and it would be
          interesting to see how it differs from that. Have you looked at that
          prior work re protection and restoration?
          Pascal: Aware of MPLS TP, where you have 2 non-congruent paths, where
          you decide to use plan B when plan A has issues. Argue that with DetNet
          we’ve gone beyond that concept because as soon as you do replication
          and elimination how can you say what path the packet has tacken? The
          packet has been through both paths.
          Lou: This would be good in the new break out meetings we will have.
          Pascal: Prior history of the term Path, thus we have effectively defined
          Segment and a Track is a graph of Segments.AGREEMENT: Agreed we will
          split. Agreed we will address the 3 missing items. Agreed we will have
          informal but regular meetings.Reasonable dates? Would be pleased if by
          next IETF in March 2022 everyone involved in reviewing the current doc is
          happy. If do bi-weekly calls, then Last Call soon after next IETF. May
          IESG submission. Defer to the list for the timing for the Framework.2b)
          groups document the technologies they are working to describe what can
          be achieved with those technologies.
          In the case of RAW, we selected Wi-Fi 6 and beyond, IEEE 802.15.4 TSCH,
          3GPP 5G, LDACS.
          Document very stable. Review from Rocco di Taranto went deeply into
          the text, with focus on 802.11 and TSN. Also 6TiSCH text. v04 now ready
          for WGLC.
          Rick: The comments raised were about standards in flight. Valid to say
          other SDOs are working on this problem, e.g., TSN in 802.11 is a classic
          example. Call out however the accurate status at the time of publication.
          Pascal: And state where the work is happening.
          Janos: See this progressing and happy for the contributions. Get into gray
          area, yes it is understood the work is ongoing, e.g., WiFi-7 and subwork
          items and so on, when approved work. But when it comes to individual
          contributions that are not yet adopted by the IEEE, they are not in the
          draft yet, so is hard to know what the WG will approve or accept. There
          were a few comments left open. Make this decision point what goes into
          the document to conclude the open items.
          Rick: Task Rocco and Dave and possibly Janos as well, to review the
          references to technologies in other SDOs, specify different ways to
          refer to the different levels of maturations. Part of the validation
          pass. 4 week Last Call.
          Eve: Half a dozen unresolved. Come up with classification that labels
          the accurate portrayal of the maturity.
          Rick: When we send out the Last Call, we explicitly state we require
          the references to be reviewed.
          Rocco: Most of the comments related to ongoing projects, and one or two
          related to proprietary projects, so they should not be there.
          Rick: Even if proprietary work, it still shows interest in the community.
          Pascal: We need to qualify. Even if just research it is good to know. We
          simply need to be very clear.
          Janos: Not sure re proprietary. It is not available to the general
          public. It is not reliable and available; it is not available if
          proprietary. Vendor lock.
          Rick: Enumerate the technologies that exist. As a general review of
          the State of the Art. Proprietary art shows interest in solving at
          the link layer. If beoame open standards then they could be used by
          RAW. Demonstrates interest.
          Pascal: He is inbetween the two opinions!
          Rick: Take to mailing list.3) IPv6
          Options for DetNet – Pascal Thubert - 10
          discussed concept of path vs flow, the idea that the path is the network
          layer, whereas the flow is the upper layer.
          Application flows can be mixed.
          DetNet has two sublayers: forwarding sublayer of operation that needs to
          be scheduled, whereas service sublayer is where you do the upper layer
          services like PREOF (where most of but not all of PAREO is there).
          Looked at how we could signal the DetNet info that is not signalled so
          far. DetNet says use the flow and then have to configure for every new
          flow. Not very practical because the pipes have longer lifetimes.
          IPv6 has 3 main types of extension layers: Hop by hop (HbH) must be
          processed by every hop, but can be ignored; Destination Option (DO),
          supposed to be processed by destination; Source Routing Header, like
          segment routing.
          At some hops exists the service sublayer operation, which includes PREOF,
          HbH, DO+SRH (if SRH signals service-sublayer relays).
          The Value: separate the app flows from the net operation that allows
          you to merge multiple flows inside the same path.
          The HbH is the first thing after the IPv5 header. One of the difficulties
          in that space is not going deep into the packets, because the ASICs
          typically process less than something like 100Bytes. There would be no
          way for the HW to detect the info. Since early in the packet, this is
          good to us HbH.
          This only draft aware of where we effectively use the IPv6 to signal
          DetNet and we need it for RAW because we have a concept of Path and
          Flow. However is useful beyond RAW thus published to DetNet. DetNet
          does MPLS they can do a lot more stuff. Wanted to make IPv6 have richer
          options here.
          Soliciting review.4) Use Cases – Carlos Bernardos - 20
          minshttps://datatracker.ietf.org/doc/draft-ietf-raw-use-cases/8 use
          cases in the draft.
          For each have the structure: use case description, spsecifics, challenges,
          need for wireless, reqs for RAW.
          After IETF 111, included discussion about non-latency critical
          comms. Received good review from Corinna, with update available after
          the meeting.
          Q: WGLC? Aligned enough with the Industrial Requirements doc?
          Obviously that one is more detailed, but cross referenced now.
          After this meeting: 4 week Last Call to give
          folks time for reviews.5) LDACS – Nils Maeurer - 20
          updates. Currently at v09. Major update not only to reliability
          and availability, but also reworking security. Streamlined the
          organization. External reviews from Routing directorate.
          Lots of questions re what is LDACS! Largely focused on safety and
          security of a flight. Network access layer, enabling aircraft comms
          with ground. Because of so many regulatory changes to docs, specifying
          the aeronautical comms over IPv6 infrastructure, other regulatory docs
          heading in this direction as well.
          What will run over LDACS in what timeline? Timeline 2024 earliest
          roll-outs, possibly more like 2026 due to Covid. EU, Asia, US, then
          worldwide 10-15 years.
          For Security, certain latency requirements, e.g., for some message types,
          within 10 seconds delivery. Although seems like a long time, when at
          edge of a cell where the error rates go up, it is not considered long.
          Laid out a public key infrastructure. Also clarified security levels
          with regards to pre- and post-quantum computing.
          Common control - when aircraft are allowed to send user data. Must ensure
          those who are requesteing the data are allowed to obtain the data.
          Given that the feedback was addressed, what next? IESG goes to all the
          Areas, so will take a bit of patience.
          John Scudder: Will try to get those reviews moving faster, for Security
          area in particular.
          Rick: Please WG members reread.6) Discussion/Open Mic

Generated from PyHt script /wg/raw/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -