Date: Tuesday, November 9, 2021 - Session I
Time: 1200-1400 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/ietf112/?group=raw
Session materials: https://datatracker.ietf.org/meeting/112/session/raw
Shared notes: https://codimd.ietf.org/notes-ietf-112-raw
Note taker: Eve Schooler
https://datatracker.ietf.org/doc/draft-ietf-raw-architecture/
Confusing 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 available.
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 network.
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 control.
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.
https://datatracker.ietf.org/doc/draft-ietf-raw-technologies/
Many 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.
https://datatracker.ietf.org/doc/draft-pthubert-detnet-ipv6-hbh/
Already 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.
https://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.
https://datatracker.ietf.org/doc/draft-ietf-raw-ldacs/
Many 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.