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

[Janos Farkas <[e-mail]>]

Dear Pascal, all,

Many thanks for the updates!
Really great improvements towards architectural cleanliness.

Otoh, distillation may reveal further questions and further distillation. 😉

For instance, now that it is called PLR, it triggers a couple of questions on my part. (Well, with the assumption that I have some clue on PLR.)

Perhaps one step back first:
We actually introduced the division of DetNet data plane to Forwarding sub-layer and Service sub-layer for architectural cleanliness during DetNet data plane design team discussions. Furthermore, in order to divide (and conquer) in the sense to be able to identify the functions and to place them to some order, i.e., for functional decomposition.

I suppose, the RAW architecture would follow DetNet architectural principles and place the RAW related functions accordingly.

I think RAW, i.e., wireless aspects actually rather reside in the Forwarding sub-layer (not in the Service sub-layer).
The Service sub-layer is pretty much IP in this case. Ideally, it is hidden from the Service sub-layer as much as possible what kind of forwarding is used in the Forwarding sub-layer, e.g., whether it is wireline or wireless. (Well, the Forwarding sub-layer may provide some certain APIs towards the Service sub-layer if we want to.)

As I read, the 1st paragraph in section 4.3 is actually along these lines
https://www.ietf.org/archive/id/draft-ietf-raw-architecture-14.html#name-raw-and-detnet
“RAW leverages the DetNet Forwarding sub-layer”
“RAW enhances DetNet to improve the protection against link errors such as transient flapping that are far more common in wireless links.” – Well, this reads to me to be in the Forwarding sub-layer.

However, I’m quire unsure of the beginning of the 2nd paragraph in section 4.3:
“RAW extends the DetNet Stack (see fig 4 of [RFC8655<https://www.ietf.org/archive/id/draft-ietf-raw-architecture-14.html#RFC8655>]) with additional functionality at the DetNet Service sub-layer for the PLR operation.”
and the location of PLR in Figure 4, where the PLR is not in the data plane.

I think PLR should be located in the Forwarding sub-layer, but I may have misunderstood the intention.

As far as I understood, the intention with the PLR is fast reaction to actual wireless situation, i.e., where to send a given packet actually.
Imo, this is very similar to FRR, see, e.g.: https://datatracker.ietf.org/doc/html/rfc5286. A key aspect is that the alternate next hops are precalculated. That is, it resides in the data plane, no control plane reaction is needed.
I guess a more recent (segment routing) document on the subject with PLR in it is: https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa, see, e.g.: “no need for any co-ordination or message exchange between the PLR and any other router in the network.”
Note that segment routing is part of the DetNet Forwarding sub-layer (not the Service sub-layer).

Perhaps I’m the only one with these kind of thoughts.
If not, then perhaps it might be good to converge on PLR (e.g., its location in the architecture) before figuring out what actual changes are needed in the draft.

My 2 cents,
János

ps:
Sorry for late commenting. It was not the plan. And now we are hit by August = vacation. I’m not sure how much I can chime in the discussion from vacation. I just thought sharing the comment instead of waiting till September.


From: detnet <[e-mail]> On Behalf Of Pascal Thubert (pthubert)
Sent: Sunday, July 30, 2023 10:39 PM
To: [e-mail]; Adrian Farrel ([e-mail]) <[e-mail]>; Greg Mirsky <[e-mail]>; Lou Berger ([e-mail]) <[e-mail]>
Cc: [e-mail]
Subject: [Detnet] Terminology: draft-ietf-raw-architecture-14.txt and what's still nuclear


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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Envoyé : samedi 29 juillet 2023 15:40
À : Pascal Thubert (pthubert) <[e-mail]<mailto:[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