[Raw] Terminology: draft-ietf-raw-architecture-14.txt and what's still nuclear

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear all:

the publication of 14 adds terminologies and typos. The goal is to serve as the new reference for the WGLC so we can use the new terms in our discussions. If someone still uses PSE and Track, well, I guess we'll still understand for a little while, but he will be harshly reprimanded.

What I did not do yet though I started is work out the positioning of the aCPF (the component that talks asynchronously to the rCPF == PCE to report performance and get route updates), the Point of Local Repair (PLR is the term that replaces the PSE) and the OAM supervisor that triggers OAM and aggregates results for the PLR.

These are 3 new architectural blocks, and we want to position them well in the DetNet architecture.

The DetNet architecture (section 4.4) has 3 planes that are mapped to classical SDN, with the controller plane in the middle, a southbound interface to the network plane (in the case of RAW used between rCPF and aCPF) and a northbound interface to the Application Plane.

The Controller plane has the typical route servers like PCEs, and network management entities. In the SDN model they are "far away" and monitor the whole network. Which is what causing the RAW issue of lack of reactivity and pushed us to port functionality in the network plane. In networking planes parlance, the PCE is control plane and the NMEs are management plane.

As we see, though the term controller plane looks like control plane, they are different beasts. A classical IGP is a control plane function that operates in the DetNet network plane. The controller plane hosts controllers, which physically may embed routing and management entities. In the DetNet architecture, "The Controller Plane corresponds to the aggregation of the Control and Management Planes in [RFC7426<https://datatracker.ietf.org/doc/html/rfc7426>], though Common Control and Measurement Plane (CCAMP) (as defined by the CCAMP Working Group [CCAMP<https://datatracker.ietf.org/wg/ccamp/charter/>]) makes an additional distinction between management and measurement."

In my book, the OAM supervisor, the aCPF and the PLR operate in the control plane. The OAM supervisor talks to the OAM handlers in the management plane. And all of the above being distributed in the network, they operate in the DetNet Network plane.  So 1) we extend the DetNet architecture to place functional blocks in the Network Plane and 2) one could say we need 3D pictures to represent the intersection of the DetNet planes and the traditional control and management planes. While the data plane remains firmly in the Network plane.

Now this is my view and the way I intend to update the text to publish 15, hopefully quite soon. But I need confirmation that we are on the same line, or else debates to reach a consensus.

What do you all think?

Pascal
________________________________
De : [e-mail] <[e-mail]>
Envoyé : samedi 29 juillet 2023 15:40
À : Pascal Thubert (pthubert) <[e-mail]>
Objet : New Version Notification for draft-ietf-raw-architecture-14.txt


A new version of I-D, draft-ietf-raw-architecture-14.txt
has been successfully submitted by Pascal Thubert and posted to the
IETF repository.

Name:           draft-ietf-raw-architecture
Revision:       14
Title:          Reliable and Available Wireless Architecture
Document date:  2023-07-29
Group:          raw
Pages:          43
URL:            https://www.ietf.org/archive/id/draft-ietf-raw-architecture-14.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-raw-architecture/
Html:           https://www.ietf.org/archive/id/draft-ietf-raw-architecture-14.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture
Diff:           https://author-tools.ietf.org/iddiff?url2=draft-ietf-raw-architecture-14

Abstract:
   Reliable and Available Wireless (RAW) provides for high reliability
   and availability for IP connectivity across any combination of wired
   and wireless network segments.  The RAW Architecture extends the
   DetNet Architecture and other standard IETF concepts and mechanisms
   to adapt to the specific challenges of the wireless medium, in
   particular intermittently lossy connectivity.  This document defines
   a network control loop that optimizes the use of constrained spectrum
   and energy while maintaining the expected connectivity properties,
   typically reliability and latency.  The loop involves OAM, DetNet
   Controller Plane, and PREOF extensions, and specifically a new
   recovery Function called PAREO and a new Point of Local Repair
   operation, that dynamically selects the DetNet path(s) for the future
   packets to route around local degradations and failures.




The IETF Secretariat